One of the most popular posts that I’ve made had to do with the issue of writing code.  (see Security v Development)  This is important because we spend a lot of time, money, and effort trying to compensate for errors and omissions made when code isn’t properly checked and validated.   One of the points that I brought up is many software engineers have never been taught to code securely.  When the subject of security did come up it was often something that they’d “take care of later after we get the system working.”

This is another reason that I was overjoyed to read CSO Senior Editor Joan Goodchild’s January 12^th article entitled Security Expert’s ID Top 25 Programming Errors: Group hopes list of 25 most dangerous programming errors will lead to safer software, better education for programmers. 

The article highlights the efforts of some of the most respected security experts and organizations in the world today.   The impetus for the initiative came from the U.S. National Security Agency (with some financial support coming from the U.S. Department of Homeland Security – National Cyber Security Division.) and it was managed by MITRE and the SANS Institute. 

The initiative breaks the top programming errors into three categories:

• Insecure Interaction Between Components (9 errors);
• Risky Resource Management (9 errors);
• Porous Defenses (7 errors).

The significance of this initiative can’t really be understated.  Prior to this we took a symptomatic approach by focusing on the vulnerabilities created by programming errors.  With this initiative we can change our focus to what is causing the problem in the first place.   Each error is accompanied by extensive prevention and remediation steps that can be used by programmers.  The information is spread out between the SANS Institute and MITRE websites  (PDF Document link provided) but it appears to be well cross referenced so as to be easy to use. 

If you are in any way connected with the development of software (anything from managing the project to writing actual code yourself) I urge you to check out the Top 25 Programming errors at either the dedicated SANS Institute or MITRE websites.

Tags: CSO, Department of Homeland Security, DHS, Joan Goodchild, MITRE, National Security Agency, NSA, programming errors, SANS Institute, Secure Code, secure programming, Security vs Development

There is a great post over on the Guerilla CISO.  The post is a guest post by a friend of mine and wonderfully illustrates how seeking to be merely compliant with current regulations can sometimes lead to problems when faced with a crisis. 

I won’t take any wind out of the author’s sails by commenting further right now.  Check out “Could the Titanic have changed course?” over on the Guerilla CISO.

Tags: Compliance, Guerilla CISO, Titanic

Hello all.  I’m putting together material to write a book that is slated for publication Spring 2009. As part of the research effort I’m conducting a short and decidedly unscientific survey. The survey should only take > about 5 to 10 minutes to complete. I would love to have your feedback. 

If you have the time and are so inclined, you can find the survey at: http://www.ascensionriskmanagement.com/BlogOne/polls/

If you could also be so kind as to pass it along to anyone who you think would be a good respondent I would greatly appreciate it.

Tags: book, polls, survey

Recently I was asked to review an upcoming work by a friend of mine in which he touches on some of the legal aspects of digital forensics.  As I was reading the document it struck me how much of what we do has a legal driver.  Now really this is something that we all know but that we rarely give much notice to so the thought occurred to me that it would be beneficial to go back and review some of the legal implications of what we do. 

Thus starts a new series of posts entitled Legal Implications.  Right now I only have a few of the topics mapped out and trust me there is almost no end to the list of what we can discuss under this heading.  For the first post I’ll be dealing with setting the stage for this discussion with a talk about some of the types of information that we need to protect as well as some of the main risks to this information. 

We will then move on to assessing regulatory obligations before finishing with looking at possible third-party liability.  During this discussion we’ll touch on the Financial Services Modernization Act of 1999, better known as Gramm Leach Bliley or GLBA, and the Health Insurance Portability and Accountability Act, or HIPAA, as well as a few other U.S. Federal and State statutes.  Now my focus will primarily be on U.S. law but I may also briefly discuss some of the international laws as they come into play. 

Let me also say that while I come from a family of lawyers, I am not a lawyer and what I’ll be giving is a layman’s interpretation of the topics that I’ll be covering.  Nothing that I’m going to write should be construed as legal advice or in any way definitive.  While it is useful to have a familiarity with these topics, you should always consult a qualified legal professional whenever you deal with these issues. 

Setting the Stage

How much of the work that your company does can survive without computers?  If you were to shutdown every system within the company how much work could actually be accomplished? 

For better or worse our organizations are dependent upon information systems.  We communicate through them, we conduct business transactions through them, we do our accounting through them, we conduct and store research and development information on them.  You get the picture; just about everything we do is tied to information systems. 

We have been able to increase productivity and efficiency through the use of information systems so this on the whole has been a good thing but it also means that we are dependent upon them in order to function.   Our systems have become increasingly interconnected which increases their functionality as well as it increases the risk in operating them.  Awareness of these risks has lead to the enactment of various laws and regulations with regard to how sensitive information is treated and handled.  These laws can impact how we implement and interconnect our information systems not only within our own environments but also with our business partners and customers. 

What types of information do we need to be concerned with?  Well here is a brief list:

• Confidential Proprietary Information (trade secrets, customer lists, etc)
• The personal information of employees and customers
• Confidential information of a business partner

There are laws on the books which protect a company’s right to information as well as laws that dictate the responsibilities that a company has in protecting the sensitive information of others.  An interesting example of this is the 1985 case of Defiance Button Machine Company v. C&C Metal Products Corp[i].  In this case the court ruled that since Defiance did not properly protect their customer lists that they had lost their status as trade secrets and therefore forfeited their rights to them.  Is your company properly protecting its trade secrets?

If you are going to establish an appropriate information risk management program you need to know how your critical information enters your systems, how it is processed, everywhere it is stored, and how it exits your systems.  That way you can implement the appropriate and required security controls.  What kinds of controls are we talking about? 

• Physical Security Controls
  • Your typical “gates and guards”
• Technical Security Controls 
  • Logical security such as access control, user provisioning, network segmentation, etc
• Managerial Security Controls 
  • Appropriate policy and procedures with regard to security. These typically cover everything from employee hiring practices to disciplinary procedures to training and awareness.
• Operational Security Controls 
  • These involve how a business operates and how it accounts for its own unique risks and vulnerabilities.

Now that we have set the stage for our discussion we can move onto assessing regulatory obligations and the potential for third-party liability under civil law.  I’ll be dealing with these issues in upcoming posts. 

 

---

[i] DEFIANCE BUTTON MACHINE COMPANY, Plaintiff-Appellant, v. C & C METAL PRODUCTS CORP. and Defiance Button Machine Company, Inc., Defendants-Appellees., 759 F.2d 1053 (2d Cir. 1985)

Tags: confidential, GLBA, HIPAA, implications, law, legal, personal informaiton, personally identifiable information, PII, proprietary, trade secret