Since the first part dealt with SMART requirements, most of the future sections of this module deal with various requirements. Some are security, some are integrity, and some are more general. This particular section now deals with the core security requirements. Dealing with Core Security Requirements address how to satisfy the CIA which is confidentiality, integrity and availability. Confidentiality as an area of security, is typically associated with encryption. We need to document how we will protect, for example, personally identifiable information or some sort of algorithm for key lengths of security.
There’s overt attacks as well as covert attacks. Overt attacks can be somewhat averted by cryptography and masking as requirements. Masking is for example the asterisks marking the letters, masking the actual password. Covert attacks might include steganography. Steganography is where there is a message embedded within another messages. This is a way that a lot of viruses can come into an unsuspecting host computer, when the user is clicking internet-based material and doesn’t realize how easy it is for a virus to be coded in a picture, for example. This is steganography. We may want to document how we will address this and prevent modification and so can guarantee that this won’t be an issue for the organization. We want to document how we are going to address confidentiality. Another issue associated with confidentiality is that there are three states that the data can exist.
The three states of the ways data can exist are “at rest”, “in process”, and “in transit”. When addressing confidentiality, data when at rest should always be encrypted using no less than AS 256bit for encryption. When data is in process, there’s actually not a lot to be able to protect it. Once it is being accessed, it must be decrypted to get loaded into RAM while the representative is working on it. Then once the representative is finished working on that one piece of information, it gets recrypted for storage. So, there’s not a lot that you can do to encrypt while data is in process. On the other hand, you can follow good security requirements that are more behavioral and habitual in the way you manage your desk.
For example, having a good clean desk policy, make sure that others can’t read your screen while you are working. Also, make sure that someone isn’t shoulder surfing, looking into your system as you are trying to work on it. Other hints are such as locking your desktop prior to leaving your work area. All of these are techniques as to following good security requirements when data is in process. The third state where data is in transit has its own security protocols like SSL or TLS or IP set. So, regardless of which is chosen, the data still must remain secure. How are we going to address privacy needs while at the same time, fulfilling what the client has requested, with the production of our software is at the heart of maintaining security requirements while data is in transit. The three states that data can exist all have certain techniques to make sure that you’re following good security requirements and thus meeting the C of the CIA, which is maintaining confidentiality.
The second element of the CIA is the I for integrity. So, in the protection and avoidance of modification of the data, and making sure that the software or the system will perform the way we want it to, this all deals with integrity. This is making sure that the file hasn’t been modified for example protection against code injection. Code injection is a huge problem when allowing for the user to put into the system some of their information. So, we have to make the external and internal values consistent. There are examples of ways to prevent modifications For example, having log files and then also having CRC’s, checksums, hashes, message digests, MACs for emails, and other methods to prevent against modifications. Others also can include messages with digital signatures and input validation as a way of documenting for the integrity requirement. Others include some sort of message digest to guarantee that the information .that they are downloading whether it be for a file or a whole system All of these could be ways we could monitor it and that we can guarantee that another company, will get what they paid for and when they load up the application, that there’s not any modification and we have in fact maintaining the integrity.
Not only is there security requirements for integrity, but there’s also the maintaining the integrity of the system, software or file so that it continues to maintain its integrity and doesn’t become corrupted through use or through being available on the internet. Associated with that is how available is the product. If you’re servicing the product, then it’s offline. But, if you don’t ever service it, then how can you maintain its integrity? So how we can guarantee its availability and when it is “up” is through a service level agreement (SLA). If the product doesn’t meet their needs or isn’t available as when they need it to be, perhaps we can financially compensate them for the failure. This is something that would be in the SLA as well. What would be the tolerance level that the customer allows for data loss is the recovery point objectives. How current must the data be, what’s the maximum amount of time they can tolerate for the product not being available while it’s being serviced or if there’s something needed to be fixed on the product. Software should meet the availability requirements as indicated by the customer. Once integrity is met with security and then maintenance and servicing, there’s also the A part of the CIA triad. A is usually for availability as discussed previously. But it can also mean authenticity, accountability and authorization.
Authenticity is associated with proving that the user is the person they say they are. There can multiple levels of authentication. First is where the user has anonymous access and no authentication is necessary. This is like a purchase website, because you want anyone to come and make purchases. The next level is basic where it is password protected and it appears on the network as clear text. There’s all kinds of ways to indicate authenticity. There can be smartcards, certificates, biometrics involvement, and so on. Then, the next level is multifactorial authentication. This is like submitting a password and a smartcard. Or, another example of multifactorial is a thumbprint and a password. There’s just more than the one aspect in order to get it. There’s different types of authentication and there’s different access control models to ensure that the authentication process is working.
Mutual authentication is where the user is proving who they are to the server. But, then the server has to authenticate back to the client. So, now this is leading into authorization. Authorization is what you are authorized to do; what activities can you perform and we’ve already talked about that a little bit. Basically, working to ensure that each member is working with least privileges whereby you’re given the minimum rights and privileges and following that protocol. It’s being given the minimum for you to do your jobs, so that you don’t end up after one job keeping those same rights and then after the next few jobs end up having administrator level rights because of the cascading effect of the collective rights. So, there’s also an acronym called CRUD. It’s create, read, update, delete. So, the updates are all about what level within the organization and trying to maintain minimum level of permissions and rights to get the job done but also not inadvertently provide someone with administrator rights.
There’s also different access control models which we’ve talked about already. There was the DAC, MAC and RBAC which were the discretionary access control, the mandatory access control and then the role-based access controls. The fourth one that wasn’t discussed already was the RuBAC. This is the rules based access control model. This is like when a firewall is used or any filter, blocking content for example. The idea of this model is based on rules like the if-then logic. This is another way where you could control access and require authorization before allowing accessibility. Some examples of authorization requirements may be to restrict access to classified or highly sensitive information to only those with Top Secret clearance. Those users that are unauthenticated will have a permissions that allow them to read the material perhaps at a public reading page, but without proper authorization, not go any further. Accountability is the next topic. Accountability and auditing go hand in hand.
Accountability is the ability to trace the action of a single user. In some of the smaller offices with like 10 employees for example, there were some companies which would allow all the employees to go on one user account. The problem with multiple users is if somehow a file is modified, how will you know who made that last modification without separate identities as could be identified when having separate user accounts. In terms of other accountability requirements, that there should be a log for login failures, with timestamps and the IP address from the attempt sourced and kept on this same log. Audit logs should have hashes to guarantee no modifications, so you know you can look at this log and no modifications have been made. Then we can go back to the integrity requirements and add this in as a guarantee towards the integrity of the program or software, as well. Other aspects may include length of time for retaining the logs, what would happen in an overwriting event, once the audit log is full what step would be taken and so forth. All of these issues and questions would be addressed in with accountability requirements.
This part of module 2 primarily deals with core security requirements such as those that follow the CIA triad – confidentiality, integrity, availability, authenticity, accountability and auditing for the maintenance and servicing of the product delivered to the client. In the next section, rather than the security requirements, we’ll be discussing general requirements.