A few years ago I had a client that had tried many different approaches to raising security awareness in his company. He was a high-level
director in the Information Technologies section of a software company, and he reported directly to a vice president. His company was a fast- growing firm, mainly through the acquisition of competing companies. Security had always been an afterthought for their organization, and he feared that things had gotten out of control.
Inside the company, several groups had created their own networks and private connections to the Internet. Additionally, as they acquired new companies, these groups were rapidly connected to the internal networks and allowed to maintain their own connections to the
Internet. Devices were popping up on the company networks at the rate of several systems a day, and they had no control over the deployment and no idea what all was out there.To make matters even worse, they had deployed no internal control methods, many of the employees in the purchased companies were openly hostile, and they were being rushed to market with a new e-commerce product offering. My client felt that things had to change before major damage occurred.
His team had tried, unsuccessfully, to raise awareness using the stan- dard methods.They had created user groups, performed internal evange- lism, hosted various security meetings, had outreach seminars for
developers, and much more. Finally, as a last resort it was decided that they needed a vulnerability analysis and penetration test to give the com- pany examples of the risks they were facing from the public Internet.
The tests began after all the contracts were finalized and the scoping of the testing was performed and agreed upon. Immediately, risks became vulnerabilities, and within hours, many systems were compromised. A soft- ware development group had left their systems unprotected and connected to the Internet.These systems were used as launching points to attack the internal network. Over the next few days, my team compromised many systems and thousands of accounts, finally ending with the capture and compromise of their newly deployed e-commerce systems.
In the weeks that followed, we created reports and gave presentations to many of their management teams and IT staff members.There were a few political situations, but overall management was responsive when confronted with the truth.The security group received their additional funding, and staff members were added as well as supplemented with consultants. Over the next year, the director rebuilt the network,
deployed the e-commerce systems in a more secure fashion, and today is well on his way to regaining control and establishing safe management. New systems are no longer added to the network without appropriate migration planning, and connectivity is becoming centrally managed. They have added a complete incident response process and intrusion detection measures.While not all of the uses of this strategy end this successfully, this was one case where things turned out well.
Possible Results of Failure
The fear tactic approach is not without its drawbacks. As expressed ear- lier, there are times when using this approach has come back against the security team itself as management ends up feeling that they have not functioned properly and blames them for the current problems.While this is not common, it is certainly a risk when dealing with this strategy.
Political problems often arise from this approach as well. Groups that are exposed as having been vulnerable are often blamed for the damages, or may become difficult to work with in the future.The best way to control this side effect is to continually reinforce that individuals are not to blame, but that the whole process requires change and better control. Extra effort to build relationships with the affected groups and offers of assistance with repair are often helpful as well.
Another problem with fear tactics is that sometimes management responds by creating a rush to “get secure.” Often this problem leads to large-scale panic and chaos.The best method to avoid this problem is to create a step-by-step process for implementing the required solutions prior to presenting the results of the testing to the management team. In this way, you can better control the responses and demonstrate that you have a plan for resolving the issues without the need for panic. Careful application of the repair process can bring value to the security team and enhance its image within the company.
Additionally, a fear tactic often leads to a cycle of breaking systems to prove that they are insecure, rather than reaching a point where security operations happen proactively.The greatest danger here is to those sys- tems that the team is not able to prove vulnerable—they may not be repaired despite your knowing that they may be vulnerable by an attacker with the proper skill level or resources. For example, your secu- rity team may not have the resources to properly design an exploit for a specific buffer overflow, but attackers may have access to a working tool outside of public knowledge. If you are caught in this cycle, you will need to break out of it by immediately stepping back and using an approach such as the yardstick method discussed earlier. Continuing to feed the “prove it or lose it” cycle only does your team and your organi- zation a disservice.
Even with all the negatives this approach can provide, it is the most common method used for raising awareness in an organization.This often leads management to be distrustful of its results and methodologies, because they have heard similar scenarios many times and they often feel that the security team is crying wolf. If this is the case, you have to be able to demonstrate real-world exercises that lead to serious damage for the site and its clients.You also have to be able to deliver the solutions if they fund them, or you may find yourself polishing your résumé.