Since this is the second module of CSSLP Tutorial
The information from the first module is understood and comprehended and can be a foundation for the information in this main section. So, part of this section is going to be based on that framework and continue to build an understanding over the material. Part of this section is where there is a focus on software that is secure by following secure software requirements. So, we need to ensure that the requirements we gather are good, strong and accurate requirements. The poor requirements might lead to client dissatisfaction, as we are not meeting their expectations and even if we meet them, because we’ve chosen poor ones, the customer remains unsatisfied.
Software requirements are essential and if good ones are not gathered properly
Then we are not meeting the customer’s needs. There are several different kinds. First is known as “SMART” requirements which stands for S=specific, M= measureable, A= attainable, R = realistic and T = timely. For example, the concept of developing software program that increases client satisfaction, while it sounds good, what does it even mean? So, having the SMART goals can aide a person in deciding what the program’s requirements should be.
There’s several types of requirements we will be discussing for example, core security, general, operational and so on. In the core security requirements there’s ones we want to make sure that there’s no problems with input validation. We want to provide support for encryption and really anything that revolves around CIA triad, as discussed in module 1, part 1. The C is for confidentiality, the I is for integrity and the A is for availability. There’s other aspects to think about as well, as in authenticity, authorization, accountability and auditing. All of these aspects tend to fall under the auspices of core security requirements.
The core security requirement being the first and foremost is a new philosophy
Traditionally, operational requirements had been the focus with security almost as an afterthought. Our functional baseline needs to be more about meeting the security requirements as it is meeting the operational requirements, or it doesn’t meet them at all. Instead of what people commonly think of as completing the product and then add a security patch later, we need to have the security aspect as integrated within the operational requirements. In the second module, not only will we be discussing core security and operational requirements, we will also learn about general ideas more associated with scalability, performance and functionality issues and so on. There’s quite a few requirements we need to gather and make sure they reflect accurately what the client needs.
CSSLP Tutorial: What the client needs and their expectations
It also have to be matched with various categories of requirements. However, there are some requirements which don’t fit into any of the otherwise mentioned such as international, tracing, and “other”requirements. The requirements associated with differences because of it being made in a different country. In addition to the ones that deal with getting information gathered for your customer. Those tracing requirements which help to keep track of different elements and trace those elements back to specific stakeholders, are all examples of requirements which don’t fit perfectly in any one sort of spot.
Part of the issue of satisfying the needs of our customers and/ or stakeholder is the realization that not all stakeholders are equal. So, we need to figure out which of the stakeholders are the most important, will have the greatest influence on the project overall, and then meet them and understand their expectations. As we go through and create our software program, we are needing to create ties reflecting that for each of the main elements, there is a connection, back to the stakeholder who originally requested for the requirements in the first place.
CSSLP Tutorial: Policy composition helps to make sure that the application supports the business objectives
It helps to support the organization overall, and also help in making the PNE (protection needs elicitation). The PNE with basic information coming from the customer, is used to try to figure out what the customer needs to protect, to satisfy their needs, to match what we are trying to do and also to help with security vulnerability issues.
So, in CSSLP tutorial, we can on purpose, work the program to avoid the Use/ Misuse probability by making the usage of the program really easy while the misuse is very difficult. Last part for this section, overall, is data classifications because different sets of data will have differing needs and therefore, will need to be treated differently. So, we need to understand classification as it relates to gathering the requirements. As we wrap up this first part, just remember that our next part for module 2 will deal more directly with core security requirements, and we will spend more time exploring those concepts.