Safety & Security

An interesting point that came out from the IET conference on System Safety incorporating the Cyber Security in Edinburgh this month is that in German the word Sicherheit means both Security and Safety depending on the context. This highlighted the commonality between building safety systems and secure systems and ensuring flaws, vulnerabilities and risk are taken into account during the requirement phase of a project and then built in during the design and production. Naturally as security & safety are parts of requirements the testing will ensure these requirements have been met and to complete the lifecycle the maintenance of the system needs to ensure the requirements are continued to be built into the systems.

Techniques from writing safe code and for writing secure code are interchangeable and ensure that software flaws such as buffer overflow, inadequate input validation are eliminated. For those writing secure code the more mature safe code standards can help with guidance in the coding of projects ensuring that the effect of unexpected features are eliminated.

Buffer overflows are still a common problem with modern software, 50% of CERT advisories still have buffer overflows despite them being known since 1972. The techniques for preventing and detecting them are well understood by programmers and testers however they are still being found by researchers in software that has been deployed.

Adherence to coding standards and use of secure and safe programming techniques will reduce vulnerabilities in software, with web application attacks being the most common attack vector along with social engineering reducing the number of flaws in applications will reduce the number of successful attacks.

Secure Software Development

There are a number of good resources on secure programming from Microsoft describing a secure developmental life cycle and tools. If you are programming with Microsoft tools then it is recommended that you look at their resources, however the resources are not just of interest to the their development environment but are applicable in many cases to others. In just the same way, there other resources that will help if you are developing using the Microsoft tools such as OWASP and (ISC)2.

Microsofts Security Development Lifecycle (SDL) 

http://www.microsoft.com/security/sdl/default.aspx

The Microsoft Site gives a lot of information on using a Secure Development lifecycle much of which is transferable to other development environments, the principles behind the Microsoft's SDL and pretty much good solid principles.

Free tools from Microsoft

Some of these tools are more for the Microsoft programming environment than others

Threat Modeling Tool

The SDL Threat Modeling Tool helps engineers analyze the security of their systems to find and address design issues early in the software lifecycle.  To help make threat modeling a little easier, Microsoft offers a free SDL Threat Modeling Tool that enables non-security subject matter experts to create and analyze threat models by communicating about the security design of their systems, Analyzing those design for potential security issues using a proven methodology and suggesting and managing mitigations for security issues.

http://blogs.technet.com/b/security/archive/2012/08/23/microsoft-s-free-security-tools-threat-modeling.aspx

Attack Surface Analyzer

Attack Surface Analyzer can help software developers and Independent Software Vendors (ISVs) understand the changes in Windows systems’ attack surface resulting from the installation of the applications they develop.  It can also help IT professionals, who are responsible for managing the deployment of applications or the security of desktops and servers, understand how the attack surface of Windows systems change as a result of installing software on the systems they manage.

http://blogs.technet.com/b/security/archive/2012/08/02/microsoft-s-free-security-tools-attack-surface-analyzer.aspx

Anti-Cross Site Scripting Library

The Microsoft Anti-Cross Site Scripting Library V4.2.1 (AntiXSS V4.2.1) is an encoding library designed to help developers protect their ASP.NET web-based applications from XSS attacks. It differs from most encoding libraries in that it uses the white-listing technique -- sometimes referred to as the principle of inclusions -- to provide protection against XSS attacks. This approach works by first defining a valid or allowable set of characters, and encodes anything outside this set (invalid characters or potential attacks). The white-listing approach provides several advantages over other encoding schemes.

http://msdn.microsoft.com/en-us/security/aa973814.aspx

banned.h

The banned.h header file is a sanitizing resource that is designed to help developers avoid using and help identify and remove banned functions from code that may lead to vulnerabilities. Banned functions are those calls in code that have been deemed dangerous by making it relatively easy to introduce vulnerabilities into code during development.

http://blogs.technet.com/b/security/archive/2012/08/30/microsoft-s-free-security-tools-banned-h.aspx

Real-World Developers Still Not Coding Securely - Dark Reading

An article about the lack of implementation of Secure Development Lifecycle by real world developers on the Dark Reading website

Real-World Developers Still Not Coding Securely - Dark Reading

One of the problems highlighted is the programmers are not trained in secure programming and much of the lack of training comes down to a lack of time, as a developer is only productive if produce code for an application and there is a demand to get applications out quickly.

Learning secure coding principles and implementing them takes time that the business is just not giving its developers, however Universities and Colleges should be helping business by teaching at least the basics of secure programming to undergraduates.

However it is not just secure programming that is important but the testing of the finished application before release has to be complete and cover testing for vulnerabilities.

The article does finish with a quote from Rob Rachwald, director of security strategy, Imperva, "SDLCs are nice but vulnerabilities are inevitable and enterprises shouldn't let secure coding practices lull them into a false sense of security."