The Product-Process chasm - and how to bridge it
Posted on: 23-Aug-2014Author: cmk
Have you implemented a firewall? An IPS? An AV? An IAM solution? A DLP? A DRM? An APT solution? A gateway proxy? An MDM solution? An SIEM? Chances are that you have answered “Yes” to at least two questions. (If not, please leave the information security industry right away and do something else. Really. Anything else will do!) All these are very good technologies. They solve an information security problem, and they solve it well. What worries me, is that many (if not most) implementations of these technologies are not as effective as they can me. The problem? - Lack of well defined processes. After labouring through days of discussions (and PoCs) with the vendors and the OEMs and “implementation partners” and creating a business case for the technology and then discussing with your boss, the purchase guys, the finance guys, your IT guys, etc - you finally start the implementation of the product. The team that comes on board for implementation wants to finish it as fast as possible and move on to the next project that they might have. Once the green light is running on the device and some data is being seen, they will thrust an implementation form at you, get it signed and never be seen again. Yes! The new product is working! What do you do now? How are you going to handle alerts that the system generates? How are you going to handle the changes that need to be made to that system? How do you know that the performance of the system remains consistent? How do you know that you have not signed a giant exception form that makes the device useless? How do you know that the dreaded “allow any-any” rule has not been implemented in your firewall over the years? Who is responsible to upgrade the system? What will you classify as ‘incidents’ and take action? What will you classify as ‘benign’ and let it be? How will you ensure that more alerts are generated for actionable incidents than just general warnings? How will you improve this system over time? How do you know that the device is effective and remains effective? Whew! That is a lot of questions to answer. I am sure, you would have thought about a few things before signing on the dotted lines. You may have completely outsourced the management of this device, thus rendering some questions moot. However, many of these points will be tackled as an afterthought. People will be assigned responsibilities. Business stakeholders will be asked and they will refuse to have anything to do with it. You will follow the general way of doing things in information security. Do you see the gap? The gap between defining a process and implementing a product? While the product vendor knows exactly how to implement his product and has detailed plans to execute the implementation precisely, you are the one who has to figure out the ‘run-and-maintain’ bit of the product. Here are a few tips that you can use to prepare your processes for a better product implementation. • Apart from an access control matrix for your product, also have a process control matrix. Think of all the processes that you need to implement and make a RACI matrix for it. You can make something simpler as well, depending on your requirement. For example, for the IPS, you can define a process for routine updates, one for configuration changes, one for incident identification. You can interlink the incident processes to ensure that you are not repeating activities. • Identify processes that need to be followed by business owners before you buy the product! A painful task, but best done before the product is bought, rather than trying to find someone afterwards. • Identify skills required for the run-and-maintain. You would have already identified that you may need more people, or more time to do the job, but write down the skills that are required for this. There is a major gap between ‘knows business process’ and ‘knows information security’. If you need a business process guy and you recruit an infosec professional to your team, chances are that the product will have a less than optimal implementation. The product-process gap is very real. You need to identify it, define the processes and implement the product for a proper implementation of any security product.