In the previous section, we just talked about security requirements. In this section, we will be discussing more of just general requirements. There is a short segment over operational requirements as well. Three of the main general requirements are session and error management as well as the third which is configuration parameters.The first one is session management, that allows us to track the state of a connection. When we talk about errors and exceptions, we sometimes get a message to the user and we have certain requirements about those messages and such. The way the web applications will configure the files via passwords and by coding. There are other general requirements associated with the operations of the system, with the sequence and timing of the system, as well as international requirements and last, the procurement requirements.
The first general requirement is session management. Each session shows a tracking of the connection and we want to avoid a user having to authenticate over again each time they try to access the subject. So a lot of times, we will use a session ID information in order to maintain the session for that one user. There has to be a place to store the information in plain text, as when a session becomes hijacked, that could be one of the pieces of information the person is trying to hijack out of the system. The activity needs to be tracked, but also decisions about whether the session is over when the person closes their browser or perhaps, after a certain amount of inactivity, or what all is in place for terminating the session? The session ID information also needs to stay encrypted as well.
The second general requirement is error management. So, we want to know how an application handles errors and exceptions. Sometimes, when the message pops up to let the user know that there’s a problem, we have to find ways that the message doesn’t expose more information than necessary to reduce the vulnerability of the system. So, a big part of what we have to deal with is what information will be displayed so as to reduce violation of the mechanism. So, that’s error management.
The third general requirement is referred to as configuration parameters. This is how the web applications configures the files. This also refers to how the password is hardlined in code and then by looking at the coding, we can’t reverse engineer what the passwords are. There’s also some monitoring and regulating of global variables. So, the three general requirements are session/ error management and configuration. What’s next is operational requirements.
Operational requirements are more about how the application functions. Some major issues associated with this involve the application’s environment, fitting into that specificity, describing the specific designations as well as archiving the information about the application. All of these issues are describing the operations of the application and so fit into this type of requirements. Archival of information can be done on logs, files, information about how to access the applications, ways we demonstrate that the application hasn’t been changed like modified or tampered as well as licensing keys and performance requirements would all be catalogued in with operational requirements.
There are yet even other requirements to consider under the main heading of general requirements. These are referred to as race conditions. It’s when there’s a problem with sequencing and timing. Race conditions are pretty rare, but it’s when there’s an attack and something is forced to happen out of sequence. As an example of this, remember the I-AAA (which stands for Identification -Authentication – Authorization – Auditing) and what the general dogma or pathway in sequence as expected. Generally, authentication occurs before authorization. But, if it’s possible to speed up authorization and slow down the authentication, the authorizing part could possibly be completed prior to the completion of authentication. This is one situation of what’s known as a race condition. It’s pretty rare, but does happen and the attack can occur just about anywhere. Basically, it can occur where something is out of sequence and/ or timing. So, for this reason and others many countries still have limits on cryptosystems being imported. So, the next general requirement being discussed is international requirements.
As far as international requirements, there are issues of systems being imported to their country and there are issues of systems coming into the US. There’s an agreement called the Foster agreement which forbids the exportation of crypted systems especially to certain terrorist states,from the US. Alternatively, there are many countries which forbid US systems to be imported to them anyway.They are especially those applications with strong encryptions. So, in terms of International Law, we have to make sure our system fits in well with those requirements. The last general requirement is the procurement requirements.
In terms of procurement, these requirements should be pretty well spelled out in the SLA or the service level agreements. The SLAs need to be written well enough so that to ensure compliance on the part of the vendors and what will happen in case of no meeting obligations, including auditing features, compensation features, and expectations and consequences for the vendors and their roles.
There are several general requirements we discussed. They all play a role in completion of our application or system we are working on. They are the requirements to consider after the security requirements are completed. There are session and error management, configuration parameters, operational requirements, race conditions and the sequencing/ timing requirements, international requirements, and procurement requirements.