SB 1386 is something most of us havent heard of. In the PCI and (fading) ISO juggernaut, organizations (especially outsourcing companies) have not taken cognizance of an important legal statute that might be a game changer for the way they do business with their principals in the US. Let me throw some light on what SB 1386 is all about. This is based on a conversation I had with another person from the outsourcing industry. The conversation might make a lot of sense to many people reading this....
What is the SB 1386?
SB 1386 is popularly known as The California Breach Security Information Act. It was an act enacted in the year 2002 and came to effect in 2003. The act focuses on the privacy of the personal information of the citizens of the state of California. The act states that any organization that believes that there has been a breach of un-encrypted personal information of California state residents is required to disclose the breach publicly.
What is 'Personal Information'? It is very vague...
No, its not vague. The act defines 'Personal Information' as the individual's first name or initial and last name in combination with one of the following: social security numbers, California State Identification Numbers, Credit/Debit Card numbers, PINS or access codes.
Ok. I am listening. Who does it apply to?
It applies to anyone doing business with anyone who is a California resident. If you have employees or customers in California, even a single one, it applies to you. If you are an outsourcing company that has a customer who has employees or customers who are California residents, then it applies to you. If you store data for entities that have information of California residents, then it applies. Large and small does not make a difference. It applies all the same.
That's alright. Its just a disclosure clause. No big deal....
That is where you are very wrong. You will have to disclose the breach to all those affected by it. These leads to a public relations war which you might have to wage with a great deal of reputational and financial expense. Your reputation WILL go to the cleaners because of a breach. You WILL face lawsuits from angry consumers and IF you are an outsourcing company, your customers will probably walk away from you and your prospects will NOT return your calls. Catch my point?
Yes, I think so. Wow, that seems worrying. I am an outsourcing partner for a lot of clients in the US. Can you tell me how it affects me?
Well, for starters if you are call center or a similar entity making outbound calls to US customers, you probably have the information which is defined by the act as "personal data", then you are in scope. If you are a back-end data processing center handling accounting or payroll or any other data processing activity for your client, then you are in scope. You will need to start securing all that data and doing it seriously. A lot of companies have breached your customer's data and you dont want that to happen. See here and here
I think I need some water now. My throat has gone dry. Anyway, what do I do now? How do I prevent a disaster from occurring?
For starters, call in a professional to audit your information security practices and let it be a thorough technical review and not a documentation and policy audit. Conduct a risk assessment for the data you handle and store and then formulate protection strategies in conjunction with your client. Have the auditor issue a formal audit report on completion and please, for heaven's sake, follow all the advice which you have been given. Dont try and cut corners on security practices, you will be in for a rude shock. Also be especially vigilant about employees who are working in your processes. It is very important to conduct periodic assessments and actively investigate any traces of malpractice from employees. Remember that insiders are the greatest cause of data theft in your industry.
Right then, but didnt you say something about encrypted data. So, if I encrypt data will I not have to disclose?
Well, yes, but have you encrypted data? and are you confident that your data has been consistently encrypted and the encryption keys managed properly for all your encrypted data?
I dont think I have encrypted any data. I am not really sure. I have got to check......
Then you most probably wouldn't have. Anyway, you better get going and do something about SB1386 otherwise you might be in for a world of pain. Think on the lines of being shot in the face with an AK-47.
(Gulps) Yes, not a pleasant situation. Anyway, I got to go. See you then...
Bye...
Sunday, November 15, 2009
Thursday, November 5, 2009
A Possibly Fresh perspective about Secure Code for Software Development Companies
I am sure most of you wont believe the reasons for my hiatus for almost 4 months. Let me try and explain. I was involved in a theater production very dear to my heart, so my evenings would be lost in that. I am pursuing a heavy writing assignment, which has been uber-demanding on the small space of time I have left and I actually took my vacation in September, when I had been to beautiful South Africa. Great place! You guys must all visit.
Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.
I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.
Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.
Let me know what you think of this....
Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.
I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.
Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.
Let me know what you think of this....
Subscribe to:
Posts (Atom)