Navigating Secure Software Development in CISSP Domain 8
To Download the FREE PDF of MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Hey, I’m Rob Witcher, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to secure software development in Domain 8, to understand how they interrelate, and to guide your studies.
This is the first of two videos for domain 8. I have included links to the other MindMap videos in the description below.
Secure Software Development
System Life Cycle (SLC)
Let’s define the System Life Cycle, the SLC, which is the overall life of a system from cradle to grave, and it encompasses, the Software Development Life Cycle. The SLC includes planning, designing, development, testing, and operations, maintenance and eventual disposal of the system.
Software Development Life Cycle (SDLC)
The Software Development Life Cycle (SDLC), as the name implies, focuses on the development phases.
Plan + Mgmt. Approval
Starting with defining a plan for a project, what goals and objectives will this project help the organization achieve, what are the high-level cost estimates, and obtaining management approval to proceed with the requirements analysis
The requirements analysis phase is were business requirements (user needs, the type of data to be collected, stored, processed, the business uses of the system) are gathered and validated to create a detailed set of requirements.
The design phase is where requirements are transformed into detailed system design documents including the architecture, security controls, screen layouts, and so forth.
The development phase is where the coding begins. Writing code to create the system. There are many methodologies that have been developed over the years to guide the development process and I’ll cover just a few key ones.
Waterfall begins with a plan, then defining requirements, building, testing and finally releasing
Cannot go back
The defining characteristic of waterfall is that each of these phases are conducted one after another and you cannot go backwards. Water can only flow downhill. So, if you discover as part of a 2-year waterfall project that you missed a requirement, you can’t go back and re-define the requirements. You must proceed through build, test and release, and then include the missed requirement as part of the next waterfall cycle.
Agile was created to address this problem.
Agile follows exactly the same phases as waterfall, but does them in, typically, 2-week sprints. Rapidly iterating through plan, define, build, test and release. Waterfall is better suited for projects where no changes are planned, and agile is better for projects where many changes are expected, where organizations want to rapidly iterate ideas and fail fast through rapid sprints.
Agile includes the role of a scrum master. This person is a facilitator, and I am intentionally emphasizing that word: facilitator. A scrum master has no real authority over the team, they are not project managers, but rather there to act as a coach to the team and facilitate communications with the organization to maximize the productivity of the team.
And of course, the latest, and debatably greatest, software development methodology is DevOps. This is what all the cool kids are doing.
Combine Dev, QA & Ops
DevOps, as the name implies, combines development (the Dev part), quality assessment, and operations (the Ops part) to significantly shorten the development lifecycle, possibly to the point of releasing new code daily. DevOps includes automated practices such as continuous integration and continuous delivery.
DevOps can seem contradictory to having security in the development process as sacred security practices like Segregation of Duties between, development and operations are intentionally removed. And many other traditional security techniques are too slow to fit into the rapid iterations of DevOps. Therefore, integrating security into DevOps requires strong engagement between developers and security, using secure development frameworks, automating much of the security testing, and only using traditional security testing techniques, such as penetration testing, sparingly.
It is very important to test throughout the system lifecycle from validating business requirements, reviewing designs, testing units, interfaces, integration and whole software systems during development and operations. I cover these testing techniques in detail in the first video for domain 6 which I’ve linked to.
One particular software development testing technique that I want to highlight is canary deployments. The idea is to gradually release new features to a subset of user as an early warning system to see if anything breaks before releasing to a wider audience. Like the canary in a coal mine.
An important topic that I’ll cover in domain 3 are evaluation criteria. Basically, independent objective evaluation and measurement of vendor products from a security perspective. These evaluations involve two major steps, the first is certification which is the independent comprehensive technical analysis of a solution or a product. Certification fits here under testing within the SDLC. The second part of evaluation criteria, the accreditation which fits under deployment.
Deployment is the final stage of the Software Development Life Cycle, and Deployment is where a system is moved into production.
Accreditation is the official management signoff of certification for a set period-of-time. In other words, Accreditation is where management says we signoff on this particular product being used in production for this period of time. So, this Accreditation step fits here under deployment.
Operations is where the system is being actively used for business purposes. It is in operation.
The disposal phase is extremely important and often overlooked. When a system is retired and replaced there needs to be controls in place to ensure data, logic, processes, etc. are migrated to the new system with integrity, data in the old system is retained as necessary, and if the old system and data are to be deleted, the data may need to be defensibly destroyed, and not just left on a hard drive that is sold on eBay. Hurray for privacy breaches.
Maturity models can be a useful tool in software development and operations. Maturity models enable the repeatable evaluation and benchmarking of processes using well defined levels starting at the bottom with level 1 which is called initial or ad-hoc, and moving up through 2. Repeatable, 3. Defined, 4. Managed, and 5. optimized. Level 1 ad-hoc basically means you have no processes and it is barely controlled chaos, and the other end of the spectrum is level 5 optimized which is an uneconomical and unobtainable goal for most organizations.
Here is a maturity model specific to software development
And here is a more generalized common maturity model for various types of processes across an organization. I would pay particular attention to this common maturity model, as it is very commonly used in organizations, and it is not uncommon to see questions on the exam about this model and its levels.
Now let’s talk about Application Programming Interfaces, APIs, which are the system of tools and resources which allow two applications (for example a Client & server) to talk to each other across a network. APIs are used pervasively in software development as they enable developers to make repetitive yet complex processes highly reusable with a little bit of code. There are two major protocols used for creating APIs. REST and SOAP
Representational State Transfer, REST, is the most commonly used and is lightweight and fast
Simple Object Access Protocol, SOAP, is far more complex and heavyweight, but accordingly provides a lot more capabilities.
Code obfuscation is the deliberate act of creating code that is difficult for humans to understand. Why would on earth would we do this? To make code more difficult to reverse engineer and conceal the purpose of the code. Code obfuscation is used when we don’t want unauthorized people to understand how our code works and what it does.
Lexical, Data, Control flow
There are three major methods for obfuscating code:
- Lexical obfuscation modifies the look of the code (changing comments, removing debugging information, and changing the format of the code) Lexical is the easiest to do but weakest form of Obfuscation
- Data obfuscation Modifies the data structure (use of variables, arrays, etc.)
- And Control flow Modifies the flow of control through the code (reordering statements, methods, loops and creating irrelevant conditional statements)
If an organization is acquiring code, by contracting an organization to write custom code, or buying some off the shelf product, then the organization needs to conduct some software assurance activities to ensure the code is free from vulnerabilities and functions as intended
An important part of this processes is assessing the vendor that is providing the code to ensure they use secure software development techniques, sufficiently test their code, etc.
Contracts / SLAs
Contracts and SLAs are an important tool that an organization can use to define the controls that a vendor must have in place, and measure the effectiveness of these controls through metrics and reports.
Software Security Weaknesses & Vulnerabilities
Now let’s talk about some common software security weaknesses and vulnerabilities that we need to ensure we put controls in place to avoid while developing software, and tests we conduct to detect during the development and operational phases.
Buffer overflows is a condition where a program, while writing data to a buffer (to memory), overruns the buffer's boundary and overwrites data into adjacent memory locations. Put more simply a program attempts to write a chunk of data to a buffer, and the chunk of data is larger than the buffer. Risk occurs when the overwritten data is read and executed by another program.
To protect against buffer overflows, code should always be written to perform parameter, or bounds checking – to never allow a chunk of data to be written to a buffer that is larger than the buffer. Another technique that can be used in Address Space Layout Randomization (ASLR) which gaurds against buffer-overflow attacks by randomizing the location where system executables are loaded into memory.
SQL injection is where malicious Structured Query Language (SQL) code are inserted into a form field on a website, sent to the web application, and then the web application passes the malicious SQL code onto the database essentially allowing the attacker to directly control a database that they should have no ability to control. I’ll be creating more detailed videos on SQL Injection, and the next few topics XSS, CSRF, covert channels, and backdoors as part of domain 3. I’ll link to those videos when they are done.
The major way to prevent against SQL injection is to perform input validation. The webs application should never allow SQL code from a user to be passed directly to the database. Input validation is also how we protect against the next topic: Cross Site Scripting
Cross Site Request Forgery attacks on the other hand target a web application. This is accomplished by tricking a valid and authenticated user into sending commands to a web application that trusts the user. The web application executes these commands from an attacker that it shouldn’t be executing.
Covert channels are an Unintentional communications path that has opportunity to disclose confidential information. There are two major types of covert channels: storage and timing. And storage is by far the most common.
Backdoors / Trapdoors
Backdoors, also known as Trapdoors, are an intentional covert method of gaining access to a system and bypassing the normal authentication and encryption controls. An attacker will install a backdoor in a system, or hide one in code, which allows them to gain unauthorized access to an application or system.
Memory / Object Reuse
Memory reuse, or Object Reuse, is a vulnerability in the way memory is allocated to applications. If an application A has stored some data in a section of memory, and then no longer needs that memory space, then the memory space can be deallocated, and then reallocated to another application, say application B, and the risk occurs if the data that application A stored is still in memory and is now accessible by application B. To prevent this vulnerability, the operating system should ensure memory is zeroed out before being reallocated to another application.
TOCTOU, Time of Check Time of Use, also known as race conditions, is where an application checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the application to perform invalid actions. In other words, an attacker attempts to race in and change a resource (a file, a variable, or some data in memory) between when the resource is checked and used.
Citizen Developers are employees from business operations that are empowered to create applications through all the new tools that make programming accessible to basically anyone. The risk of Citizen Developers is that you have people creating applications, that shouldn’t be. They aren’t properly trained developers, so they inevitably create insecure code.
Some secure programming techniques that we can use to address the vulnerabilities we just discussed include
Input validation. This is a major one that commonly comes up on the exam as a method for prevent XSS and SQL injection attacks. Input validation ensures only properly formed data is accepted and thus malformed or malicious input is rejected.
Input validation can be achieved through:
- Syntactical validation where the syntax or structure of the input is enforced
- Semantic validation where the correctness of values is enforced (for example the start date is before end date)
Session management is where we carefully manage user’s sessions. When a user is authenticated and authorized to access an application, this begins a session, and session management is concerned with ensuring that a session is allowed to be created (not allowing more than one session for each username) and terminating sessions when they are not being used through the use of timeouts and screensavers. Proper session management helps to prevent session hijacking.
And finally, Polyinstantation, allows different versions of the same information to exist at different classification levels. Polyinstantation can be used to prevent unauthorized inference, by creating different objects of the same name simultaneously.
And that is an overview of secure software development within Domain 8, covering the most critical concepts to know for the exam.
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!