Presenting security to management is something all security managers must do.
In addition they must be prepared to overcome any and all obstacles and conceptions
management may have. Below are several key notes that one must remember when
presenting any security topic to management.
Figure 1:Security Pie
In the example above is a method that is used to demonstrate what makes up
security. Compare the parts of security to an equilateral triangle. An equilateral
triangle has three equal sides with three equal angles. Technology represents
all the tools that security engineers use to monitor, audit, and enforce the
Processes and People. The People use the technology and are guided by the process.
The Process is the security implementation (e.g. policies and procedures) that
security engineers put in place.
Only when all three are viewed in this form, will the security of the organization
be complete and risk will be mitigated to the fullest potential.
When presenting security, always relate security to the Business!!! Security
exists for the business and without the business, we wouldn’t need security.
Security protects the business and Effective security reduces risk to the business.
This ideology will help your business partners understand what you’re relaying
to them, in a language they will understand. Remember, the goal of security
in business is to help ensure confidentiality, integrity, and availability of
data and resources.
The Scale of Security
It helps to give examples of levels of security on a scale (perhaps a fruit
scale). On one hand you have no security, the left hand side of the scale, with
operating systems and applications installed out of box and not maintained or
adjusted with security in mind. The other side of the scale, the right hand
side, is a locked down infrastructure with no access to anyone and everything
is locked down to the point it becomes unusable to the business (but at least
it’s secure!). As a security administrator, it is important that you find
a happy medium on that scale. A good example of that is demonstrated in Figure
2 below. This slide was taken from a presentation from Data from Dr. William
M. Hancock, Exodus, A Cable and Wireless Service.
Figure 2: Scale of Security
Management has several questions that must be asked. When presenting security
to management, the following questions should be answered in the presentation.
- What should we do?
- How much should we do?
- Why should we do it?
When developing a security policy, all employees in the organization are a
part of it. It should offer guidance to all levels of staff. In addition to
this, it is important to keep the following points in mind when developing or
presenting security to offer guidance and points that should not be forgotten.
One day, an employee called me with great concern. It seems that the company
we worked for changed the authentication process to access their employee benefits
that they have. The authentication now required the users Intranet ID. The user
exclaimed: “I have told many people what my intranet authentication is,
and I have it written down on my desk.” I proceeded to explain that they
are responsible for their authentication credentials. The user explained that
they did not know this. Something that seemed to basic, was not made clear to
the user. Therefore, it is important to remind everyone that they own it and
are responsible for it.
- Everyone owns it
- Everyone must use it or it won’t work
- Not everyone wants it
- Nobody wants to be responsible for it
- Everyone is accountable
The following are bullet points that should be used in any presentation on
security. They are common knowledge to security staff, but are often not recognized
or forgotten by management. The last point is something I find I tell my Engineers
all the time as they look for a “Stamp of Security”. I simply explain
that I can help determine an acceptable level of risk with the business.
- You are never 100% secure
- Mitigation is acceptable risks : Acceptable risk is defined by the business
- Security is a process, not a product
- Technology alone is not the answer
- You never achieve Security (or a secure state)
There are 3 parts to security: People, Process and technology. The point is
focused on the processes of security. First, remember that processes are more
important than technology. For example, the password security is a good example
of this. There are settings in a Microsoft Active Directory that require a complex
password that must meet a certain number of characters. Even with such technologies,
it is easy for users to continue to use non-complex passwords, or easily guessable
passwords. Adding a process like an educational class that instructs users on
creating complex passwords would considerably increase the security of the organization.
Technology should support the processes. Using the password example above,
after educating users, the technology staff can use the settings in AD to help
enforce a more complex choice. The implementation of security is as important
as the technology.
There are constant changes in the people, security and technology today. These
changes bring new vulnerabilities. The new vulnerabilities bring new risks.
New risks bring new mitigation methods. At a SANS course, it was taught that
security is complex, technology is complex. Therefore, in this complex environment,
we should keep it simple.
Additionally, with all the changes, it is very important that security staff
continue to do their best to keep up with current technologies, risks, and vulnerabilities.
There are many recurring themes, or “Catch Phrases” that are repeated
over and over when discussing security. I have listed several that I have heard
- Defense in Depth
- Least privileged
- Security stance (allow/deny)
- Risk management
- Acceptable risk
- SANS offers a class for Information Security Officers. One section of the
class focuses on this very topic. In addition, a perspective from different
people in the organization is outlined. http://www.SANS.org
- Computer Security. Matt Bishop. Published by Addison-Wesley. 2003
- A presentation by Matt Tolbert (http://itanium.ee.ualberta.ca/hpw2002/paper/7094.pdf)
gives a good example of how Business processes are complex, Application architectures
are Extensive, and IT infrastructures are non-trivial. With all that in mind,
the risks of exposure to security vulnerabilities are greater than ever. The
complexity Matt refers to gives a prime reason as to why security should be