NoticeBored blog

An ISO/IEC 27000-series multi-part standard on application security is 'in the works'.

I'm currently reviewing the second Committee Draft of ISO/IEC 27034-1 "Information technology — Security techniques — Application Security — Part 1: Overview and concepts" which lays out the basic concepts and principles for other parts of 27034 to elaborate upon.

Despite this overview section being around 78 pages in length, part 1 states explicitly that 27024 is not a software application development standard, an application project management standard, nor a software development cycle standard. Its purpose is to provide general guidance that will be supported, in turn, by more detailed methods and standards in those areas.

The standard explictly takes a process approach to specifying, designing, developing, testing, implementing and maintaining security functions and controls in application systems. For instance it defines application security not as the state of security of an application system but as "a process an organization can perform for applying controls and measurements to its applications in order the manage the risk of using them".

The draft standard draws on concepts such as auditing and certification of application systems similar in style to the Common Criteria and similar schemes primarily used for government and military systems. It tends to emphasize deliberate threats arising from external adversaries over those from insiders, and perhaps more importantly in many situations accidental threats and hence the need for integrity and availability controls.

The standard is not projected to be released until 2012 - such is the glacially slow pace of ISO/IEC. The upside, though, is that the final product will - we hope - be well worth the wait.

Labels: Development, ISO27000

In connection with this month's NoticeBored awareness materials on the security aspects of software development, I've been listening to a podcast by Ralph Hood and Kim Howell (two Microsofties) about how both privacy and wider information security issues are integrated into Microsoft's development practices.

From a non-US perspective, the very idea that privacy and security are "opposite sides of the same coin" seems a little weird. For most of the rest of the world, privacy has long been acknowledged as a subset of information security, being essentially the confidentiality of information about specific individuals. But, as host Julia Allen mentions in the podcast, the US is still shifting from the idea that it's perfectly OK to collect all sorts of personal information from people and use it as you wish.

One of the interesting approaches discussed in the podcast is that personal information needed purely for aggregation or statistical purposes should be collected and held only temporarily, then deleted as soon as possible. Personal information in server logs, for example, may be parsed out, analyzed and deleted by a regular process. While this would make post-hoc validation of the data difficult, this slight drawback is outweighed by the privacy advantages for those who supply their information.

The podcast is one of the excellent Security for business leaders series by CERT at Carnegie Mellon University. An impressive range of podcasts is available to download.

Labels: Awareness, Confidentiality, Development, Privacy

Why is it that so many organizations expect their software developers and other IT people to “do” information security, yet they don’t bother to train them in the art?

A new security awareness briefing pack contains a set of notelets (short briefings) to help those involved in managing and delivering IT system developments fulfill their information security obligations.

The notelets fall into two groups:

1. Technical notelets introduce common information security controls, explain generic control requirements and outline the options available to satisfy those requirements.
2. Development process notelets outline information security issues that ought to be taken into account during most software developments (including ‘end user computing’ projects such as spreadsheet programs).

Although all the notelets are succinct double-sided items, the briefing pack contains 33 of them and hence with introduction and copyright notice is some 70 pages in total.
Download the complete pack here (1Mb PDF file).

The editable MS Word version of the pack is available free of charge on request by NoticeBored customers. An earlier version of the pack was delivered in the module on ‘SDLC integration’ in 2006.

Labels: Awareness, Development

Through a series of nearly 300 “lessons”, the authors of Lessons Learned in Software Testing (~$27 from Amazon) share around 60 years of accumulated wisdom about how to test application systems - not so much which buttons to press but more how to establish and manage a test team, plan the work and dynamically adjust the testing process according to what is found and how much time is left.

Read our book review here.

Labels: Development

An excellent article by Ismael Valenzuela in the latest issue 11 of [IN]SECURE eZine explains how information security can and indeed should be integrated with the systems development lifecycle (SDLC), using ISO/IEC 27002:2007 (currently known as ISO/IEC 17799:2005). There is a useful table linking specific clauses in the ISO standard to SDLC phases starting from the risk assessment stage, prior to drawing up security requirements, and continuing right through development, testing and operations to eventual retirement of the system at the end of its life.

The NoticeBored security awareness module on this topic a year ago took the same basic idea one step further. The concept was simple: we provided a 'sales brochure' to help the Information Security Department sell their services to software development project managers and hence to the development teams. The brochure is a folder containing two sheafs of glossy leaflets, one set explaining the kinds of security-SDLC process integration issues covered by Ismael, the other outlining the range of information security controls that are typically required for most IT systems. Contact me (Gary@isect.com) if you'd like more information on the module but that's not a bad brief to write your own!

Labels: Awareness, Development, ISO27000

Scuba looks like an interesting option to supplement your regular pre-release security assessment processes and tools:

Scuba by Imperva is a free, lightweight Java utility that scans Oracle, DB2, MS-SQL, and Sybase databases for known vulnerabilities and configuration flaws. Based on its assessment results, Scuba creates clear, informative reports with detailed test descriptions. Summary reports, available in Java and HTML format, illustrate overall risk level. With Scuba by Imperva, you are quickly on your way to meeting industry-leading best practices for database configuration and management.

More database security links

Labels: Database, Development

Attackers are actively exploiting an MS Word zero-day vulnerability by tricking users into opening malicious Word files using a form of social engineering. Infected files may arrive as email attachments from people you know and trust, as well as from those you’ve never heard of. It’s not yet clear whether Microsoft will release a patch on Tuesday: if not the fix may slip to January unless M$ releases an interim emergency patch. It all depends on the quality of their coding and the speed of their QA and release processes. Meanwhile take extra care with email attachments, even from friends and colleagues, and make sure your antivirus software is bang up to date. We'll be releasing an updated malware module early in the new year and a new module on application security shortly afterwards: don't let your organization become a statistic or case study!
More social engineering, incident management, bugs!, secure software development and malware links

Labels: Development, Email, Incidents, Malware, Social engineering

The diagram comes from an excellent new white paper by Israeli security specialist, Danny Lieberman. It eloquently describes a systematic approach for assessing and addressing risks in legacy systems. It examines the question of why there are so many bugs (including defects that cause security issues) in software, and goes on to explain the derivation of threat models (using the Practical Threat Analysis tool) to design appropriate controls.
More risk management, secure development and Bugs! links

Labels: Bugs, Development, Risk

Microsoft’s Trustworthy Computing Initiative involved retraining loads of developers to code with security in mind. Whilst Microsoft's secure development methods generally follow the traditional waterfall approach, take a closer look at the activities immediately preceding release. “During the release phase, the software should be subject to a Final Security Review (‘FSR’). The goal of the FSR is to answer one question. ‘From a security viewpoint, is this software ready to deliver to customers?’ The FSR is conducted two to six months prior to software completion, depending on the scope of the software. The software must be in a stable state before the FSR, with only minimal non-security changes expected prior to release.” In your organization, does independent security testing occur 2 to 6 months before release?! Of course, even this method is not absolutely perfect: at least one buffer overflow vulnerability in Word somehow slipped through the net.

More security-development integration resources

Labels: Bugs, Development

Software development: Building security in explains six key issues in the software development process that lead to the release of insecure code. Unfortunately, the article does not actually describe the solutions to the six issues identified - that is left as an exercise for the reader - and there is a bias towards the use of testing tools (i.e. technology) to solve the problem. Still, it's a typical perspective, summarized succinctly.

More SDLC-security integration resources

Labels: Development

SPI Dynamics, providers of software for testing web applications etc., publishes a range of useful white papers relating to software quality etc. Unlike some of their peers, the papers are provided free of charge with no strings attached - you don't need to register, sign up for their newsletter, supply a small DNA sample or otherwise jump through hoops. Just click, wait and read :-)

More secure software development links here

Labels: Development

It has been estimated that it is about 200 times more expensive to fix a problem when an IT system is in Production compared to fixing at the requirements analysis step during Development. The factor falls to about 4 for small IT projects but can exceed 500 for very large projects. Even if these figures are only vaguely close to the truth, the implications for quality assurance processes in IT development are crystal clear, as are the benefits of splitting massive projects into discrete sub-projects.

More change management, bugs and secure systems development resources

Labels: Bugs, Change, Development