Throughout my many years of experience in the system and software development area, I have noticed one major thing that always seems to be at the top of requirements but becomes relegated to somewhere lower in priority as the project proceeds, only to come back to the forefront as testing and implementation time approach.  This is security.   Even in today’s time, with CISSP and CSSLP professionals everywhere, security seem to still take a back seat in the development process.

Most projects include building security, network security, and various other types of security policies which are generally inherited from the environment where the task is occurring and are fairly defined and stable.  Controlling access to the building, access to the network, access to files and folders, and general access to computing resources are all well established.  However, when we sit down and try to implement some form of security into the software we develop, it gets left out or deferred and needs to be added in at the last moment.  Why is it deferred? Well, how many requirements are really created around security?

Let’s throw a few examples out there:

• The system will only permit access to authorized users
• The authorized users will only be allowed to perform tasks they have been granted
• The authorized users will only be able to see the data they are allowed to work on
• The system will provide role and group based access controls
• The system will log all unauthorized access to data (is this security or logging –you decide)
• The system will log access to all data (Again, security or logging? Well, both)

These are very similar from project to project and pretty high level and very few, usually a dozen or so, but, without them in place, the system is essentially, non-functional.  Well, with the other functional requirements, what the user wants to see and do, which usually number in the hundreds, it’s easy to see why the security component gets little attention.  Except for the initial log-in, the users don’t really experience what is happening in the background, except for an odd warning about doing something they aren’t allowed to do.  A correctly implemented security model won’t even let the user know that features exist beyond what they are permitted to see.  What prevents them from seeing hidden features by glancing over their co-workers shoulder – well, that’s another issue.

So what happens when one of the most critical components of an application is not designed in from the onset? Besides chaos, a lot of redevelopment which is required to implement the missing feature, which leads to missing project deadlines and at worst not meeting implementation times. This is especially true for Fixed Firm Price (FFP) contracts where this can be disastrous to the bottom line, not to mention project failure – after all who will accept a system that cannot meet their basic requirements. Things are changing for the better, as I have seen projects now that have distinct security implementation team which interacts with the other development teams rather than being a side-attraction.

Naturally, for small scale web projects which are usually secured with 2-factor authentication (userid and password), the implementation is fairly simple and can be supported by the OS or a very simple database table.   If, however, you also need to control what the user can do (functionally) once authenticated, it starts becoming complex as you now have to maintain Access Control information for the user as well.  If you now further need to control what data they user can see, use, or modify, the security implementation gets even more complex.   Finally, if you need to implement CAC card integration, IP based authentication, CPU based authentication, or N-factor authentication (more than just a User ID and PWD, such as secure tokens, bio-metric, key-card …) , then additional complexities arise which need to be implemented in code or at the enterprise IT level.  Even now, we still haven’t addressed any encryption and data security requirements that could exist (ie. The system shall encrypt all personal data – does that just mean when it’s stored or also when transmitted??).  It is for this reason that security requirements must get high priority in any project where application, data, and system security are paramount, with the design engaged from the onset of the project.

The actual size of the security team will vary depending on the size of a project, but at least a single resource, with knowledge on all aspects of security (yes all, not just software), should be assigned as the single point of contact.  This person/team, throughout the project, must be involved intimately at the architectural level and will have the final say in any security testing scenarios.  By being involved at the architectural level, no design will be allowed to move forward until the security implementation has been vetted and approved.  Regardless of the security implementation, the primary goal is to confirm that all teams are compliant, which in essence translates to a compliant and secure application.  Whatever tests are needed to validate compliance should be defined during the design process as there is no better way to validate a system then to penetrate it by knowing its internals.  If you know how the security model is implemented and are still unable to compromise it, and then be default, the system is secure.  Open source systems fall into this category since all their code is accessible; everyone knows how to try to gain access, however, due to a well-implemented security model, they cannot.

At this point, we can keep going on about how imperative it is to make security design a high priority in any application design, or for that matter, any system design.  How would you like it if the car you bought didn’t have a lock or key to get it going?  Instead, I’ll just finish up with stressing that security is not a feature that can be put on the back-burner.  Everyone talks about it – you hear about cyber-security everywhere these days, but when it comes to the actual implementation, it gets compromised and inadequately implemented.  Considering that the raw power of computers is such that most systems can be compromised by simple attacks (such as brute force attacks), effort must be put into not just installing measures at the front gate, but beyond that as well to control losses if a breach were to occur.  It is also essential that management personnel understand this when planning a project to account for the level of effort it entails and to ensure that it is effectively budgeted for the entire project duration.

Now that we have addressed the issue of security in software system (and other systems), where do we go from there?  The best security is achieved by informing and teaching the user base, from the users up through the developers and managers.  I have covered a lot of items in this quick prelude to discussing security in information systems, but each should be followed with further details and training.