CompTIA CYSA+ CS0-002 – Mitigate Software Vulnerabilities and Attacks Part 1

1. SDLC Integration (OBJ 2.2)

Software development lifecycle integration. In this lesson we’re going to talk about the software development lifecycle and how important it is to start embedding your security in from the beginning. Now, when I talk about the software development lifecycle or SDLC, this is talking about the process of planning, analysis, design, implementation and maintenance that governs software and systems development. Now, as you should start building your software, it is important to think about security all the way from the beginning. And if you make sure that you integrate security controls into each stage of the SDLC, it will save you a lot of time and money. Now there’s really two ways to do software development. We have the more traditional method known as waterfall and then the newer method known as Agile. In this lesson we’re going to talk about both of these.

Now, when we start out, we want to talk about the traditional method which is waterfall. The Waterfall method is a software development model where the phases of the SDLC cascade downward so that each phase will start only when all of the tasks identified in the previous phase were already completed. This means we’re going to do all of the planning, then all of the requirements, then all of the design, then all of the implementation, then all the verification, then all of the testing and all of the maintenance and eventually all the retirement and that’s one version of one piece of software. And so all of these things cascade downward as we go through this life cycle. Now, when you’re dealing with waterfall, there are a lot of benefits to it. This is the way people have been doing software and projects for decades.

Now. The big problem we have with it is that when you have an idea for something and you start creating the plan and the requirements and then go all the way through the stage, this can take a long time, anywhere from six months, twelve months, sometimes two or three years. And so if I wanted to develop a brand new piece of software and I’m going to put all this money into it and do all this development and then not see anything out the other side to deliver to my customer until two or three years, that’s a really long development cycle. And if when I get it to my customer they find something wrong with it, I now have to go back to the beginning and start going all the way through that cycle again. And so this is something that gives a lot of delays.

And so if you don’t do a lot of your security upfront in your design and implementing it all the way through these phases and you try to bolt on security as an afterthought, it’s going to take a long time and you’re going to have an insecure piece of software. Now the other way we can do things is what’s known as Agile. The Agile method is a software development model that focuses on iterative and incremental development to account for evolving requirements and expectations. Now, the nice thing about Agile is that they work pretty quickly when you’re trying to develop something. I can have an idea for something and have something out in the market within two weeks or four weeks. Now it’s not going to be perfect, it’s not going to be the complete program, but it’s something.

The whole idea with Agile is getting something into the hands of your consumer and getting it out there quickly. So most of the software development you see today done by startups is done in an Agile way. They’re going to go forward and they’re going to think of some concept, they are going to have some kind of idea for it. They’re going to start the design, they’re going to start planning and they’re going to start building and they’re going to start testing. And they’re going to do this all over and over and over again in these quick loops. And then they get something that’s ready and they push out the door into production. And so we can go from idea to execution in maybe a week or two weeks, or maybe four weeks. And we do these in these short sprints to be able to get things out. The whole idea when you’re dealing with Agile is getting that product into the hands of the consumer.

And so let’s use an example of this course. I could do it as a waterfall method, or I could do it as an Agile method. If I was going to do it in a waterfall method, I would go out and outline every single video that’s going to be in this course. So I say, okay, here are going to be 38 sections. And in section one I’m going to have these videos. And in section two I’m going to have these videos. I’m going to have these lessons here and these quizzes here, and these practice exams here. And I figure out all the things I want. And then once we’ve all agreed to it, that becomes set in stone. That’s what we’re going to do. Then we start writing the lessons and filming the lessons and building the quizzes. And once we get all of those together, we take all of that, we bundle it up, we package it up and we sell it to our customers.

This is the way traditional book authors work. Because when you print a book, you can’t go back and add more pages later. But because this course is digital, I don’t have to do it in that waterfall method. Instead, I might do it in a more agile way. Maybe I would say this hey customers, I’m going to make a brand new course. It’s on cysaplus. If you want to get into it, you’re going to pay upfront. And every week I’m going to give you some more content. And so what can happen is you sign up for the course today. And this week you’re already getting the first 2 hours of the course. Next week you get another 2 hours of the course, the next week you get another 2 hours of the course. And we’ll keep doing that until you get the entire course that you needed. That’d be a more agile way for me to deliver this kind of material.

Now, either way you can do this and both of them are acceptable ways of doing things, but it depends on what is going to be best for your customers and for your consumers. Now, in the digital world, when we’re dealing with products and software, it works a lot better to do things agile. Because if I start giving you this course and the first week I get feedback from you, it says, hey, I don’t like the way you did these videos. I can actually change that and I can edit it before I go into the next section. And so we get more feedback, more iterations, and any bugs we find can be fixed even quicker. Instead of waiting for us to do six full months of development, of writing and filming this thing and then giving it to you and then finding those errors, because then we have to go back and start all over again.

That’s one of the big differences between waterfall and agile. Now, as I said, your security has to be integrated into your software development lifecycle. And there’s a couple of different ways you can do this. One of the most common ways this is done is by using security targeted frameworks. They can incorporate threat and vulnerability and risk related controls into the software development lifecycle. So as we’re thinking about the requirements and the plans and the designs and the implementation, we want to integrate the security all the way through. And so security target frameworks can help us with that. Now, in your textbook, they mentioned two types of security targeted frameworks. The first is SDL, which is a security development lifecycle. Now, SDL is Microsoft Security framework for application development that supports dynamic development processes.

And so they work in an agile way and this is a way to implement security throughout that agile process. Now, another good one that’s out there is OS. Now, OS is the Open Web Application Security Project and they have their software security assurance process.This is their security framework for secure application development. Now, if you’re not familiar with OAS, you can go to Owast. org. And this is a website that is a community funded website and community built website. They are all about making sure that the best information about coding practices is out there for the community. So, as a cybersecurity analyst, I do recommend you take some time looking at Owas and looking through their various top ten lists. There’s a lot of good information there.

Now, as we go forward and we start thinking about secure development, I mentioned that we have to start integrating it into each of these phases. For example, in the planning phase, we need to make sure we’re training our developers and our testers on the different security issues that are out there. If I start incorporating that into their training so they understand what a buffer overflow attack is, why input validation is important and things like that, they can think about that as they build their software. Then we need to think about requirements. When we’re dealing with requirements, we have to determine the needs for security and privacy. If I’m building an application that’s going to be open to the Internet, do I need a password? Well, maybe, or maybe not. If that application is to display my website, I probably don’t need a password because you just need to go to my website and read it.

But if there’s a secure area of my website, then I need to have that security put in place. So you have to give me a username and password to access that part of the site. The next stage we have to think about is design. And with design, we have to identify the different threats and controls that we’re going to use is when we design and start coding this software. Then this brings us to our next stage, which is implementation. When we’re doing implementation, we want to make sure we’re doing source code analysis so we understand what’s being written and how it works. Then we’re going to go into testing. And here’s where we want to start performing black box or gray box testing and start testing the system for vulnerabilities to see if people can break our software.

Because if they can break into our software, that means we need to fix that and go back into design and implementation to fix those coding errors. And then we have deployment. This is where we’re going to take the software and we’re going to put it out into the environment. We’re going to install it on a server, we’re going to install it on a client, and we’re going to make sure it works properly. Now, here’s where we’re going to be focused on the installer packages and the different best practices of how you should configure it. And then finally we have maintenance. We have to have ongoing security monitoring and maintenance. So we put out the software. We think it’s the best thing ever, but then there’s a vulnerability that’s found. What does that mean? Well, we have to do maintenance. Somebody has to code a patch.

We need to test that patch, we need to deploy that patch and then maintain the ongoing operations. Again, this is how we can make sure our security controls are all in place. Now, I mentioned testing, and when we talk about testing, I want you to think about the fact that there are three types of testing. We have black box testing, white box testing, and gray box testing. Now, when I talk about black box testing, this is also known as blind testing. This is when a cybersecurity analyst receives no privileged information about the software. So if I give you a binary from, say, Microsoft Windows, and I say, go ahead and test this, that is black box testing. You don’t have the source code, you don’t have any permissions, you don’t know anything about it. You just know this is a binary and you need to test it.

And so you can run different tests against it and see what you can find. Now on the other hand, if I was writing my own code, I might have you do white box testing. If I’m doing white box testing, this is also known as full disclosure testing. This is where a cybersecurity analyst receives privileged information about the software. So you might get things like the source code and credentials. So I could say, hey, I built this new app for my website to test my students. Can you go ahead and test it? Here’s the source code, and you can look at it line by line and know exactly what it’s doing, and then you can put it through dynamic testing as well. Now the other kind we have is what’s known as gray box testing, and this is kind of an in between place. This is where a cybersecurity analyst is going to receive partial disclosure of information about the software.

I may not give you the entire source code, but I might give you some information and say, this is what the thing is supposed to do. Here’s the inputs it takes. Here’s, the outputs you should expect. Here is a standard user account that you can use going against this software. And then you could do your testing with that. It’s not fully blind, but it’s not fully disclosed. So that’s why we call it gray box. It’s between black and between white. Next, let’s talk about some secure coding best practices. Because secure coding can make your software more secure and save your organization even more money. Because when you’re putting on security as an afterthought, it’s actually much more expensive than building your programs with security from the beginning. Now, to do this, you want to make sure you’re using secure coding and there’s some best practices you should be aware of.

So when it comes to secure coding best practices, there’s really two organizations that I like to think of. The first is OWASP, and the second is Sands. When we talk about OWASP or Oast, this is the Open Web Application Security Project, and it’s a charity and community that publishes a number of secure application development resources. When we talk about Sans, this is a system admin network and security institute. This is a company that specializes in cybersecurity and secure web application development training. And it also sponsors the GAC certification. The Global Information Assurance Certification. Now for the exam, let me give you a quick tip. It is worth your time to go to Owasp. org Oasp website and I want you to go there and look at their various top ten lists. When you go through those, you’re going to see a lot of things that we cover in this course.

They’re going to talk about SQL injections and XML injections and buffer overflows and race conditions and all of those type of things. And for each of those they’re going to have articles that give you examples of them, including in detail for the source code. Now, CompTIA loves to pull questions for the Cysaplus and the Pen test plus exams from Oasp. Why? Because it is a great resource and it is the most common ten vulnerabilities that you will find for any particular topic. So do spend some time looking through those. When I write my practice exams, I go into Oast and I actually pull out things from the top ten. Why? Because so does CompTIA. And so this is a great place for you to get some information. And in the real world, it’s a great place to learn some of these career coding techniques to make sure that you’re doing software development the right way from the beginning.

• Category: Uncategorized