Sunday, May 10, 2020

Repost - hints for deploying security technologies

When deploying security technology, there are a few essential things to consider:
You have picked a technology, but what does the system to actually do? How will it be configured? What reporting do you need it to produce? If it's an Intrusion Prevention System will it be configured to block or simply monitor? Document what the system needs to do, these are your requirements.
Product Selection
When you have firm requirements then, and only then, can you pick an appropriate vendor. In my experience most projects fail due to poor vendor/product selection. You shouldn't pick your security technology based on which one treated your CIO to the best lunch. Sometimes there is a complementary technology, a different vendor, or an alternative product that will better meet your requirements. In most cases there is even a solution built-in by your major vendor. You just need to turn it on and configure! Think about running a tender, or at least collecting a few quotes. Consider the impact of using more than one security vendor with a "best of breed approach", chasing only incremental improvements – integration between competing vendors’ products is never easy, even when "open standards for interoperability" are on the specification sheet.
It's important to consider where the technology will sit in your environment. For example, where on the network; in which network segment and VLAN? It may be important to decide between the additional components it needs, and hence its configuration (eg fail open or fail secure). Once the placement, interfaces and integration have been determined, it’s important to document this and share it with others. Sharing can potentially improve the design, remove your assumptions and clarify how the environment is actually set up. A mature organisation will even have a forum in which the design can be submitted for peer review and approval.
Operating model
Once you have a good idea about which security product you want, how it will be configured, where it will go and how other systems will need to be configured to integrate with it, it’s time to consider the operating model. At its most basic, an operating model is a RASIC chart documenting responsibility, accountability etc. This is important because when the system in handed over to be operated, there needs to be clarity around who is going to maintain what and, importantly, who is going to fix what when it breaks. Other components of the operating model are Standard Operating Procedures (SOPs) and "Run books". SOPs outline the maintenance, monitoring and management activities to be performed on a regular basis. Run books outline procedures and other operations to give step by step instructions for installation, reinstallation and key configuration tasks.
Think about who's going to build the system, is it better to involve the personnel who will support the system going forward?
$$$$$$$ and Resources
You may find that after thinking through the above you’ll need to re-evaluate your capital and operational expenditure estimates. It's normal for the ongoing costs of resources to monitor and manage systems to be significant. Security technology is not "fire and forget". It's usual for product licenses, hardware and product maintenance costs to be dwarfed by design and implementation costs. If they aren't you might be forgetting something important.
As always keen to hear your thoughts and experiences.

No comments:

Post a Comment