Security often seems to be an afterthought when designing applications. Some architects tend to fob off the responsibility to either some Application Server we are using, the environment team that will harden our servers, or the network team that will implement sufficient firewalls, intrusion detection gizmos and monitoring doodads to isolate our system from all the evils of the big bad outside world. This complacency will often lead to tears….
The main assumption that causes us problems is that all that is required in terms of security is, say, a SSL connection between the client web browser and the web application. However, it is never ever that easy. From the infrastructure point of view, there are trusted zones to map out, PKI certificates to manage, SSH ports to open and monitor, security schemes such as WebServices security, to implement, etc that are the devil in the security detail. In addition there is application security, encryption, authentication and authorisation, that threads its way through much of the application code rather than being bolted on as part of the architecture.
And this is the fundamental problem: Security architecture is not a black box that bolts on to the system you are building, instead, it weaves through all aspects of execution, operations, development and application architecture in non-trivial ways that usually don’t become apparent until the system is put in production.
So What Do You Do?
First gauge the required level of security early in the analysis phase of the project i.e NFRs. Does this system need to have a security infrastructure that is beyond the standard offered by industry standards (e.g. SSL)? If so select and test an appropriate product that will do the job early and integrate it as soon as possible to the code. This will be painful initially, however it will give the team much needed experience in the workings of the product that will be invaluable during technical test. In addition, it has been my experience that these products have subtle nuances and integration issues that are best identified early and their implications resolved (with aid from the vendor) as soon as possible.
Next map the zones that are trusted and untrusted and determine how data will be sent over each zone. Typically, you would want to have VPN devices installed to bridge an untrusted zone. Identify these early.
Security should have separate test cycles in technical test. At the minimum, a third party should be hired to perform penetration testing. It is important that you work with the pen test vendor to make the testing realistic. I’ve had a pen testing vendor attack a website as if it was a Unix system, when it was in fact a Windows system. Giving hints to pen test vendors will improve the quality of the pen test and give added confidence to the client that the system is secure.
For operations, think about how to limit the damage that can be done by a disgruntled employee. Limit access to a few individuals, set up audit logs and associate reports, limit or disallow direct access to the servers, instead access these via a jump server. Consider the installation of anti-virus software and schedule regular scans (out of hours). Have a scheme for expiring passwords and accounts, and make it easy to revoke privileges (best done through integration to an enterprise authentication system, rather than local privileges – I have had systems that have had accounts of users around 3 years after the employee had left).
In conclusion, security concerns weave throughout the whole system from technical architecture (development, execution and operation) to application architecture. Security should not be left as an afterthought to be dealt with at a later phase in the lifecycle, instead, should be planned for and given the respect it deserves early in a project and through every phase.
