Hints and Tips for Deploying Security Technology

Matthew Hackling

Matthew has over ten years experience operating solely in the area of information security, holds a Bachelors degree in security management from ECU and is also a CISSP. He is a former Account Director in Deloitte’s Security & Privacy Services practice. Matthew has led security testing teams on assessments of large core systems replacement projects for banking institutions. He operates more in the area of information security governance these days, despite his urges still stay a bit technical. Hence he plays with backtrack linux, metasploit and new web application security assessment tools in his rare free time. Currently he runs his own consultancy called Ronin Security Consulting and holds the title of General Manager of Security Testing at Enex TestLab. He is an active member of the Australian Information Security Association, and held the office of Melbourne Branch Executive for a number of years. Matt’s security blog is called Infamous Agenda and he is an active twitter user with the handle @mhackling

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.

Tags: technology, deployment

Show Comments

Editor's Recommendations

Solution Centres

Brand Page


View all events Submit your own security event

Latest Videos

More videos

Blog Posts

Media Release

More media release