jump to navigation

Creating Secure Software December 8, 2013

Posted by kristinamensch in Security.
trackback

In the 1994 article Why Cryptosystems Fail Ross Anderson discusses the prevalence of ATM fraud across Europe caused by security holes in the ATM software and regulatory oversight.[1] According to Anderson the majority of these attacks were not sophisticated technological attacks on cryptographic security, but simple attacks that exploited ‘errors in the design and operation of the ATM system itself’. [1] Shedding light on the actual failures of cryptographic systems can lead to better software in the future but many companies are unwilling to submit software security breeches to the industry for investigation, research, and learning. It is not surprising that companies do not want their name attached to the security holes that have led to the many cases of ATM fraud, theft, and system failure across Europe, but how will we ever learn to design and produce better, more secure software without this knowledge?

The point of today’s blog is to reflect on how security concerns can and should be incorporated into the process of software development. In my opinion security concerns should be identified and detailed during the initial requirements gathering phase. Software systems should then be designed, coded, and tested in such a way to ensure that these security needs are met. If security features are not considered at every step of the development process it may be difficult or impossible to achieve adequate security during deployment.

There is much talk in software development circles about the necessity of building quality into products and I believe that security should be viewed in much the same way. There are a number of software and hardware development companies that have each developed a software development methodology with security in mind. Microsoft[4], CISCO[2], and McAfee[3] all detail what they call a Security Development Life Cycle that outlines how to incorporate security into traditional and agile[5] development processes. These methodologies roughly apply the following steps.

  • Training
  • Requirements Gathering / Story Writing
  • System Design
  • System Implementation (Coding)
  • System Testing / Quality Assurance
  • Product Release
  • Security Response and Accountability

One of the most important components of these methodologies, in my opinion, deals with the training of business analysts, managers, developers, and testers in security concerns and current security best practices. In my studies of computer science I have taken numerous courses in systems analysis and software design and have learned about and participated in requirement gathering for projects in both traditional waterfall and agile methodologies, but system security concerns were almost completely missing from any educational project. System security and security implementations have been left to on the job training. That is why I believe it is very important to train all people who touch the software development life cycle in security concerns appropriate to their job duties. Business analysts should know how to extract the security needs for a new system from stakeholders, architects and designers should be able to translate these needs into the system design, developers should understand the requirements and be able to code to and unit test these security requirements, and quality assurance teams need to be able to validate that the software meets all of the functional and nonfunctional project requirements.

With proper training in and understanding of security needs at every step of the development process a truly secure product can be built.

References

[1] Anderson, Ross J. “Why Cryptosystems Fail.” Communications of the ACM, November 1994: 32 – 40.

[2] Cisco Systems. Cisco Secure Development Life Cycle (CSDL) . 2013. http://www.cisco.com/web/about/security/cspo/csdl/index.html (accessed December 8, 2013).

[3] Foundstone. “http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-secure-software-dev-life-cycle.pdf.” McAfee. 2008. http://www.mcafee.com/us/resources/data-sheets/foundstone/ds-secure-software-dev-life-cycle.pdf (accessed December 4, 2013).

[4] Microsoft. “Microsoft Security Development Lifecycle.” Microsoft. 2013. http://www.microsoft.com/security/sdl/default.aspx (accessed December 5, 2013).

[5] —. “Security Development Lifecycle for Agile Development.” Microsoft MSDN. 2012. http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx (accessed December 5, 2013).

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: