The issue of secure coding has been around since the first program was hacked by the first hacker and was caught.  I am sure that someone asked the developer why he coded it that way and probably got a blank look in response.  As Information Security (INFOSEC) professionals, we are often quick to fault the developers for our malicious software woes and for the most part, we have good reason.  Software products are often raced to market to capture the almighty dollar.  Software vendors often seem to pay lip service to validating their code before they go to market.  I came up with an adage when I was actually involved in day-to-day IT operations.  I believe it works here as well.  It goes something like this: “Believe only half of what a software vendor tells you about his/her product and expect them to deliver only a quarter of what you believe.”   Software vendors (the big guys Microsoft, Oracle, Cisco, etc aside) often live off their reputation so I believe that some code checking and validation does occur but probably not as much as they say they do. 

 

Does this make the software vendors responsible for all the malicious software out there taking advantage of our naïve users and robbing us of valuable bandwidth?  In some manner, yes it does.  They are not the only one’s to blame though.  How many years have we put up with this type of sloppy code?  How many years have we put up with the endless cycle of patching?  Have we passed the point where sufficient pressure can be put on the big software vendors to pay more attention to security?  Apparently Microsoft is now trying to market themselves as having a secure operating system and is getting better (relative term) in getting their code cleaned up. 

 

In a April 2004 article for Network World, Ellen Messmer quotes Steve Orrin, CTO at Sanctum as saying that “Many organizations try to stomp bugs by having the chief software architect and programmers work in a formal process with the security manager’s staff as part of the code-evaluation process.”  While this is a good development, Ms Messmer goes on to point out that, Microsoft employed “about a dozen of these security specialists to interact with about 20,000 software engineers.” 

 

Secure coding can be said to start at home.  I have talked to too many software engineers over the years that say that they never learned about security when whey were learning about programming or that they were required to take one class about secure programming.  I have heard too often from program managers on systems development projects that “we will worry about security controls later, after we get the system working.”  How much is the education system to blame for not teaching secure coding from the onset of a project?  How much of the “just get the thing working first” mentality comes from these days in academia?

 

There is a good article on this subject by David Wong; a principle consultant with Foundstone (at the time the article was written).  He points out that it is “impossible to build bug-free, vulnerability-free software.”  He approaches the point from a very realistic standpoint that software development, like INFOSEC itself, is an exercise of reducing risk to an acceptable level and by following best practices software developers can avoid 90% of the commonly exploited security vulnerabilities.  He even indicates that there are automated tools to assist in the identification of these vulnerabilities.  He also points out that it still takes a programmer to fix them. 

 

This debate has been raging for years and unfortunately, everyone involved has stopped listening to the other side.  Programmers are blaming the flaws on hackers or the rush to market or the security department for pointing out these issues.  Security professionals are blaming the latest virus outbreaks on code that should never have been released in such a vulnerable state.  Both sides have valid arguments and the best solution is probably right down the middle of both camps.  Programmers and Software development companies need to invest more time and money into some of the simple measures enumerated by Wong before they release their software.  Security Professionals need to take some basic steps to reduce their risk as well by implementing sufficient controls, turning off unneeded services and limiting access to only what is needed to perform specific functions.  Is this the silver bullet?  No but it is quite a bit better than where we are at now. 

Tags: bugs, David Wong, development, education, Ellen Messmer, flaws, Foundstone, Microsoft, Network World, patches, Sanctum, Secure Code, secure programming, Security Focus, Steve Orrin

The following is a piece that was originally written for Network World’s Security Newsletter and published in March of 2006.  It was a collaborative effort between Joe Faraone, a close friend, and I.  The issue we touched on really hasn’t gone away so I thought that I’d dust it off and update it a bit. 

Sometimes we hear senior managers and executives expressing frustration with government regulation by saying that the issue has come down to a choice of either being secure or being compliant.  In fact Compliance remains the number one driver of information security as reported in the 10^th Annual Global Information Security Survey conducted by Ernst & Young. 

This is consistent with the article that sparked the original version of this post.  That was an Information Security Magazine article from October 2005 in which security managers were asked to respond to the question, “What is your biggest obstacle to implementing and managing security related government regulations?” Responses reveal that the top two obstacles faced were unclear compliance related responsibilities and interpreting regulatory language. This point of view appears to be more prevalent in the private sector than the public sector.

One of the reasons for this discrepancy is that the public sector must follow a specific framework for measuring the maturity and effectiveness of its information security programs: certification and accreditation (C&A). The Federal Information Security Management Act of 2002 (FISMA) was intended to provide for the development of and maintenance of minimum controls required to protect information systems and to provide for a framework for ensuring the effectiveness of these controls. While many of the overriding principles followed in C&A are contained within the law, nowhere are the words “certification” or “accreditation” found.

FISMA points to the Office of Management and Budget (OMB) as well as the National Institute of Standards and Technology (NIST) to obtain guidance. OMB has issued its Circular A130, which requires that all federal information systems to be certified and accredited following guidelines developed by NIST.

Now the C&A process has gotten a lot of bad press, some of it well deserved but coming from someone who has worked with the process in one form or another for the past ten years I’d say that it comes down to a matter of implementation rather than issues with the process itself.  If the process is viewed as just another paper exercise intended to satisfy auditors then it is a waste of time but it is also missing the forest for the trees. 

NIST has done a laudable job of developing and revising this guidance. It provides a methodology to fully document, measure, assess, track and report on the health of information systems from the aspect of security. These guidelines show how to integrate an information security program with the systems development lifecycle as well as how to test the implemented controls.

Those in the private sector are probably wondering why this should be important to them.  Many argue that the control sets mandated by the process are too much for a private sector environment.  Implementing the full set of baseline controls would be too costly and provide little ROI others say.  Again, my response is that you’re missing the forest for the trees.  The process itself is what is valuable here and is flexible enough to allow any set of requirements to be utilized not just the set of baseline controls provided by NIST. 

NIST publications and the methodology for conducting certification and accreditation are freely available and constitute an untapped publicly available security resource. Inputting the government regulations (Sarbanes Oxley, Health Insurance Portability and Accountability Act, etc.) into this framework allows the private sector to document, measure, assess, track and report upon the security posture of their information systems and how well government regulations are adhered to. The private sector can assess the maturity of their information security programs and determine how well these programs integrate into their overall business processes.

What is key for the private sector is that the process must be tailored to your environment and needs.  Herein lies the problem that has plagued C&A from its beginning – it is often applied improperly. 

When the emphasis is placed on being compliant, people go through the motions and focus on technology and checking boxes rather than leveraging the power of the framework to assess the effectiveness of their programs.

The two most basic elements of any system are often overlooked or underemphasized: the information being protected and the people who use the information. You can put in all the high security devices you want in a system, but if you do not account for the people who need to use the information system and the criticality of the information within the system, you still will not be secure.

If the C&A process is improperly applied then it does result in a lot of wasted time and paperwork. If it is properly applied then it becomes a wonderful tool to assess the effectiveness of your security controls – everything from policy and procedure down to control functionality and configuration.  It provides a holistic view of the network and security with the emphasis on being secure. Compliance is simply a milestone on that journey.

The beauty of this is that the information that you need to implement this framework is _free_ and fully available at the NIST Web site. Do you need to hire high priced consultants to come and set this up for you? No, you don’t. Although consultants can save you some time on the learning curve, the guidance available through NIST will allow you to begin the process on your own. You can then use consultants to give you an independent review of your program or to bolster areas where you might feel less comfortable. But remember that you must tailor this framework to fit your environment – use what works and make sense and discard that which does not.  (Sorry government readers – this doesn’t apply to you.  You don’t have the same latitude to do that as does the private sector.)

The CIO implementing this approach can concentrate on the details of how information is protected and used rather than scurrying about wondering how to bring order to the new herd of cats that legislation has unleashed.

Take the framework that NIST has so diligently given us, plug in the requirements that you are subject to, and then sit down with your network architects, your user representatives and your key project managers and find a way to work efficiently but securely. With the NIST framework, you will be able to assess, measure, track, and deliver a more secure and user friendly network and in the process, achieve compliance.  I have done this with amazing results so I know for a fact that it works. 

Alternatively, keep enjoying your view of the forest.

Tags: C&A, Compliance, Ernst & Young, FISMA, Information Security Magazine, Joe Faraone, Network World, NIST, OMB, Published