What exactly does “compliance” mean? If I’m reviewing a product and conclude that it is compliant against some particular policy or regulation then what that really means is that it is compliant at that particular moment in time. This is a point well made on the PCI blog and it’s something that businesses should reflect on regardless of whether they are aiming for compliance with regulation or simply wanting to comply with an internal policy. The reason, obviously I hope, is that web products in particular present a moving target. A component deemed secure today might be completely insecure tomorrow when the next change is implemented .
It’s therefore important that change control includes processes for ensuring continual compliance. Changes should be reviewed for security impact, and their risk assessed. It sounds easy doesn’t it? But that’s assuming that there are suitably security-aware people available and also that the potential impact of a change can really be known. For instance, a change request to open a new port on a firewall can be easily assessed, however, a request to deploy a new customer-facing enhancement to a web product needs a diffierent approach. Having security baked into the SDLC is an obvious good place to begin however, playing devil’s advocat here, let’s say it’s a change that needs to be implemented fast to resolve an earlier customer-facing (non-security) issue. There is going to be a good deal of pressure to deploy: the business needs to maximise revenue and get the product working fast, the development group is going to be under maximum pressure to deliver fast and the developer will be focusing on the functionaility rather than the security. Can a compliant product still be delivered under those circumstances?
The answer, in my opinion, is probably no. The most likely result will be after-the-event bug fixing and a period of non-compliance. It’s an expensive way to do things and while we all know it’s cheaper to address problems prior to deployment the real-world is often not as we would really like it to be.
So, faced with a need to be compliant on the one hand but a star product requiring a quick but complex change on the other what can we do to ensure we don’t attract the ire of the auditors? PCI clause 6.6 might provide some of the solution. Namely “installing an application layer firewall in front of application.” Yes, I know that I’ve previously stomped on this clause and bemoaned the fact that it’s not problem solving from a development perspective but from a business perspective it’s a different matter because while the bugs still sit on the server, at least the device is protecting against them being exploited.
It’s not a perfect solution and I’d prefer to see more review and testing during the life-cycle but as I stated earlier, the reality is frequently less than perfect and our role at the end of the day is to adequately mitigate risk. In my mind that means ensuring that the business can still function, protects assets, and meets it’s security and compliance obligations in the easiest, most cost-effective manner.
So, going back to change control, which is where we came in for this blog, we need to work on improving processes to ensure that security impacts are reviewed but we also need to be aware that this cannot always be assured. When that is the case there are alternative solutions that help us maintain compliance. Make sense?