CISSP 2015 Update: Software Development Security

April 15, 2015 by Kurt Ellzey

The CISSP 2015 Update brings new viewpoints on the key domains covered in this certification. The CISSP is already one of the broadest of all certs in that the amount of information it covers in different fields is staggering. However, breaking it down into its component domains or fields can help to chop at it bit by bit. With the new updates, each domain is a bit more streamlined – a bit easier to manage in the overall picture – and becomes easier to understand.

Thus far we have covered seven of the new domains, showing what you need to know if you have just started studying for the CISSP. Right off the bat we can say that with very few exceptions, the old domains are gone. That’s not to say the information isn’t there anymore, its just that the perspectives on that information have shifted. The CISSP certification has always been a managerial-level certification – understanding is required for a lot of topics across a wide range of requirements. The new update zeroes-in on that concept: making it easier to look at things from particular scenarios with a bird’s eye view.

With that in mind, let’s take a look at our eighth and final domain: Software Development Security (Understanding, Applying and Enforcing Software Security)

Change Management

With very few exceptions, development IS change. By its very name, it is trying to take a concept and develop (help it to grow) into something useful. However, because this change is so constant, it’s easy to think that tracking those changes is pointless; that it would just increase the time required to work on the project to an impractical degree. And yet, in large projects it may be the only possible way to see who is working on a particular section. In other cases, a seemingly small change could have huge consequences on the rest of the project – especially if the person performing the change does not have the complete picture.


Going hand-in-hand with Change Management, not every person can follow code logic. Even when you are able to, it might not be easy to follow the previous developer’s line of reasoning – sometimes even when it’s your own from several years earlier. Commenting what lines do what tasks within a script or program can save a huge amount of time, and make things far easier to understand. In addition to in-line commenting however, it is also important to document why certain modifications were made – why was this feature approached then abandoned? Simple notes can help an organization to not repeat history and thus avoid the costs involved with going over past mistakes.

Secure Development Methodologies

Before development begins, it is necessary to outline exactly how far the project is going to go and no further. This means knowing from the outset if the intended deployment location is on the web, on the organization’s intranet, or in a secure network. What will it be talking to? Who will have access to it? Will it need to have privileged access to secure databases or servers? Will it be handling Personally Identifiable Information? Is this replacing an existing solution that had deliberate holes in the software? Finding out the answers to these and other questions will greatly simplify the process and help resolve issues at the development phase, where modifications can be performed more easily than at later stages.

Use of the Software Development Life Cycle (SDLC)

There are several different styles of the SDLC, the benefits of each are determined by how complex the project is and how much review needs to be done in each phase. While the ‘Waterfall’ style is the traditional method, it is considered by some to not be as efficient as the ‘Spiral’, where sub-tasks are more easily defined as the project moves in and out of various modes. Regardless of the method being used, a style needs to be selected by the organization and adhered to in order for design, review and auditing to be effectively managed.

Source-Code Level Vulnerabilities

Hard-coded backdoors, SQL Injections, cross-site scripting, plaintext passwords and other similar issues have plagued developers for decades. These types of coding mistakes (malicious or otherwise) can become enormous complications and security hazards when a project goes live. Having regular reviews can help to discover issues like this prior to deployment, but they might not always be able to be fixed. In certain cases, especially legacy code, some languages require particular methods of authentication. It doesn’t mean however that a developer can just give up and walk away from it. Security vulnerabilities in sensitive code can be a significant problem, and a business case can be made that shows what happens if that is exploited – this goes for legacy (and current) software across the board.

Auditing Development Practices

Auditing code is definitely a good thing, but it needs to be about more than just the code. For example, if the developer posts an unfiltered example of something they are working on to a forum asking for assistance to solve a particular problem, is that a security threat in your organization? Could the solution contain a potential problem down the road? Could it also be used to understand the inner workings of the organization’s environment and have that knowledge used against it? Knowing these answers, and making sure that developers know what is and is not permitted can save a lot of headaches.

Language-Level Security Issues

There are reasons why certain languages such as Java and Flash are targeted more than others – whether that is because they are more popular than than their counterparts and so its possible to get more bang for your black hat buck, or because the patch cycle for it is very long, or because they were designed for a different time – using those languages can potentially cause problems. Migrating legacy code off of vulnerable languages can not only help extend the lifetime of the code, but also make sure that any issues below the code can be taken care of more quickly.

Understanding Vulnerabilities and Threats

It is one thing to be able to catch a threat in a program, but it is another thing entirely to have the developer understand why it is an issue. Indeed, there have been some cases where a developer makes a case to a manager saying that implementing a code in this particular manner saves half a day’s worth of work. If the manager goes along with the idea, it could create a massive upheaval in the auditing process, making it far more difficult to safely release programs in the future and more likely to release insecure code in the future.

[download]Click Here to Download the Full CISSP Update eBook![/download]

Posted: April 15, 2015
Articles Author
Kurt Ellzey
View Profile

Kurt Ellzey has worked in IT for the past 12 years, with a specialization in Information Security. During that time, he has covered a broad swath of IT tasks from system administration to application development and beyond. He has contributed to a book published in 2013 entitled “Security 3.0” which is currently available on Amazon and other retailers.

Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117