Tactics: An Introduction ◾ 113
in day-to-day operations, especially in attack or breach situations. e goal of coverage is to have
skilled people always available to manage security operations and responses. is includes a staff
that has been cross trained to cover periods of illness, vacation, training, and other absences. Skills
management has already been mentioned in a previous section, and it is not our intent to beat the
point to death, but ensuring proper coverage for security functions requires a good understanding
of what critical skills are required and of managing training and staffi ng to make sure you have a
suffi cient number of people with those skills. is includes in-house expertise from IT and other
departments or divisions, as well as external expertise such as penetration testers, forensics con-
sultants, and law enforcement. If you have high-value or high-sensitivity data, you may want to
consider keeping some of these external resources on retainer or contract. Eff ective tactics require
a suffi ciently skilled staff . Tactical planning must include a thorough assessment of the knowledge,
skills, and abilities (KSAs) required for each control objective.
e coverage principle also extends to security management processes. Processes are essen-
tially a command framework, in the sense that they identify key resources and direct how those
resources will be used. Good processes ensure that the information required to make decisions
is collected and available when it is needed, and good processes provide the order and guidance
needed to make those decisions effi cient and eff ective. Process is the commander at Carmarthen
Castle going to the top of the observation tower to gather information about the enemy’s attack
points and his troop positions, and then quickly repositioning troops to counter those attacks.
Coverage means our processes are capable of eff ectively dealing with all the aspects of a situation.
From his corner tower, the commander at Carmarthen Castle could only observe attacks against
two of the castle walls. Fortunately, these were the only two walls the rebels could attack; other-
wise, the process would have required a soldier with signaling capabilities in the opposite tower.
When planning and selecting tactics, it’s not going to be possible to foresee every conceivable situ-
ation, but it is possible to build a framework capable of covering the normal and the unexpected.
is must be what we strive for in our tactical planning endeavors.
Technology is the fi nal aspect of coverage. Computing environments are so complex that it’s
nearly impossible to fi nd a single solution that covers everything. Conversely, “securing almost
everything” is an oxymoron. Security is only as good as the weakest link; leaving some things
unprotected is like locking all but one window in your house. Guess which one the thief came
through? Each of our tactics and associated control objectives must apply to all our systems and
must encompass all of the associated attack scenarios. A tactic that protects your systems from
outside attacks and leaves them wide open to insiders is a poor solution. Coverage says our controls
apply equally across our entire environment.
SIDEBAR: MAY DAY! MAY DAY!
After the 2000 May Day riots in London, Scotland Yard employed a number of these tactical principles to deal with
future May Day protests and violence. First, they increased their observation capabilities with some 2,000 video
feeds, including teams of roving police “spotters” armed with cameras. Second, they used this surveillance to rapidly
direct offi cers (with the appropriate equipment/weaponry) to any emerging trouble spot. This rapid response capa-
bility gave the respondents the edge; they were able to break up crowds before they gained any malicious momen-
tum. Scotland Yard kept a large force in reserve as well. In addition to the “all hands” deployment of central London
police offi cers, more than 1,000 offi cers from surrounding boroughs were kept in active reserve.
Redundancy Principle
Security failures are some of the most impactful events an organization can experience. ese
failures involve not only security breaches but also system/equipment failures. For example, losing
TAF-K11348-10-0301-C007.indd 113TAF-K11348-10-0301-C007.indd 113 8/18/10 3:08:06 PM8/18/10 3:08:06 PM
114 ◾ Security Strategy: From Requirements to Reality
a building or computer access control system will keep people from getting to their workspaces
or accessing the applications they need to do their jobs. ey also include failures in security
processes that create vulnerabilities, allow vulnerable systems in the production environment, or
hamper incident responses and disaster recovery. e redundancy principle states that security
functions should have no single point of failure.
Technology redundancy is a fairly well-understood discipline. Most vendor solutions have some
level of redundancy or high-availability functionality built in, and we encourage the use of these
technologies in all primary solutions. However, our tactics must include redundancy in supporting
technologies as well. Communications for incident management is a great example. When the Red
Code worm hit Dallas, Texas, it infected a large number of companies, including the company
where Bill was working. e IT security manager requested his assistance, so Bill followed him to
the War Room where the manager promptly dialed in to the conference bridge only to receive a
busy signal! Apparently, hundreds of companies were using this bridge to manage the crisis, and
there were no more circuits available. e alternative was to use the conference-calling capability
of the company’s PBX, but it was limited to 8 connections, actually 16, because the room had two
phone circuits. Now the fun began. First everyone had to be notifi ed to abandon the bridge and
get into the offi ce as soon as possible. Conference rooms were taken over at each business location
and became part of the conference call on one phone. e other phone was used to call “critical”
personnel, including the CIO, the manager of IT operations, and the network engineering lead.
Two hours later almost everyone was on board, but little had gotten accomplished in the interim
unless you consider having another thousand or so systems infected with the worm an accomplish-
ment! One other interesting resource issue came to light when the security manager attempted to
share his desktop with people in the other conference rooms. e traffi c generated by the worm
had clogged the wide area network connections, making it nearly impossible to maintain a reliable
Netmeeting connection. Even getting e-mails delivered was a challenge. e loss of the conference
bridge and network-based communications greatly impaired the organization’s ability to rapidly
respond to a critical situation, and they had no viable alternatives.
e story stands to illustrate both a technological issue and a process issue. e Incident
Response Plan had no built-in contingencies to deal with a conference bridge failure. e confer-
ence bridge was a single point of failure. If no one activated the conference, people just waited
and nothing got accomplished. Incident response is only one example of the importance of this
principle; our tactics should include redundancy for all security processes. When Bill worked at
Predictive Systems, this was known as the “four eyes” rule. According to this rule, one person
does the work and another person verifi es it was done correctly. is is the standard process for
commercial aircraft maintenance; all repairs require an inspection and signoff before the aircraft
is permitted to fl y. Unfortunately, this practice is not standard in many security-related functions.
Perhaps the best demonstration of this is the number of security failures attributed to misconfi gu-
ration. e possibility of misconfi guring a device is substantially reduced if someone is verifying
the changes to a security control. e goal of the redundancy principle is to avoid these issues and
ensure that security functions continue to operate eff ectively even in times of duress.
Least Privilege Principle
e principle of least privilege—only granting users or processes access to the resources they
require to accomplish their assigned tasks—has been around since the inception of IT security.
However, the application of least privilege in business IT systems is practically nonexistent. Part of
the problem is application related—poor security designs that require applications to be run with
TAF-K11348-10-0301-C007.indd 114TAF-K11348-10-0301-C007.indd 114 8/18/10 3:08:06 PM8/18/10 3:08:06 PM
Tactics: An Introduction ◾ 115
elevated privileges or grant excess permissions to application resources and data. e other major
problem is the lack of management tools. ere are no Top Secret or RACF management facilities
for workstations and servers. PCs may have the computing power of a mainframe, but they have
the management capabilities of a moron. Equating users with access to specifi c resources is an
arduous task even if you are using a common platform. row in a couple of diff erent platforms,
and it becomes near impossible.
at having been said, it still doesn’t change our need to protect data and computing assets.
e business process mapping component of security strategy helps address this issue by identify-
ing the key business functions and the resources that support them. Combined with an organiza-
tional chart, it makes it fairly easy to determine who needs access to what. Unfortunately, it will
not tell you what permissions they require; this is where security process comes into play. e
provisioning process must capture required permissions, and the revocation process must capture
what permissions to remove. Furthermore, our change processes must include an evaluation of
the impact of a change on access privileges. Technology solutions in this area are likely to remain
sparse mostly because of the complexity of the environment. However, cloud computing does off er
an opportunity for better management tools because the model mirrors a mainframe.
Today least privilege is really a trade-off between functionality and protection, and too often
protection is on the losing side. Our tactics should endeavor to enforce the principle of least privi-
lege in some meaningful manner. At the very least, access should be divided into three distinct
categories:
1. Viewer—someone with privileges to read information
2. Contributor—someone with privileges to read and write information
3. Administrator—someone with all privileges
Commonality Principle
Complexity is the antithesis of security; the more complex an environment becomes, the more
diffi cult it is to secure. e goal of the commonality principle is to minimize complexity through
standardization. e ideal environment from a security standpoint has all the same systems with
the same set of security controls confi gured the same way. e reality is far from the ideal; multiple
systems, confi gured diff erently, running diff erent applications, and using diff erent security controls
is the norm. To make matters worse, the data formats are diff erent too. When security information
resides in multiple places in diff erent formats, the consolidation and processing of that information
become diffi cult, time consuming, and often labor intensive. In addition, the processes do not scale,
and they cannot be easily automated. is is where commonality comes into play.
Commonality establishes consistent repeatable processes that facilitate information collec-
tion, processing, and reporting. Any process that is consistent and repeatable can be automated.
Automation increases process effi ciency and accuracy, expands the scope of observation, and
reduces response time. is is accomplished by standardizing on a specifi c set of technologies
for the storage and transfer of information, for example, using technologies with SQL Server
data stores. Having a common database technology means information can be easily transferred
between systems using built-in SQL server data connectors and database joins. Transfers can be
done continuously in near real time instead of being reformatted and processed in a periodic batch
job. SQL Server also supports another important commonality factor: scripting (customization).
e ability to customize data transfers and data manipulation means controls can be easily modi-
fi ed to support new requirements or emergency situations.
TAF-K11348-10-0301-C007.indd 115TAF-K11348-10-0301-C007.indd 115 8/18/10 3:08:06 PM8/18/10 3:08:06 PM
116 ◾ Security Strategy: From Requirements to Reality
Commonality focuses on standards rather than functionality. Standard protocols may not be
the most robust or the most secure options, but they will be the most interoperable and have the
largest selection of well-supported products in the marketplace. For example, use of a standard
alerting protocol such as the Simple Network Management Protocol (SNMP) Trap means that the
data generated on any platform (i.e., Windows, UNIX, Cisco, Nortel) can easily be forwarded,
received, and processed by most network management consoles, including Microsoft System
Center, HP OpenView, and Tivoli NetView (all of which have fully customizable alert processing
capabilities). e commonality of components and customization facilitates the collection, pro-
cessing, and reporting of security data, functions that are critical to the success of security man-
agement and the enterprise. For the primary components supporting commonality, see Table 7.1.
e commonality principle is a major contributor to the interoperability and effi ciency of our
security solutions and must be one of the factors considered when you are formulating your tactics
and control objectives.
Conclusion
Tactics are procedures or sets of actions used to achieve a specifi c objective. Before tactics can be
selected, it is necessary to break down the strategic plan into smaller point solutions to identify
objectives. Once the objectives are known, it is possible to apply tactical principles in the selection
Table 7.1 Primary Components Supporting Commonality
Factor Description
Storage Scalable data storage with the following capabilities:
1. Real-time data transfer
2. Search and/or indexing
3. Customizable data transfer and data manipulation
Transfer Scalable multipath (redundant) transfer mechanism for security data and
alerts
Format Common formats for security data and alerts including a common naming
convention for each data fi eld
Alert A scalable alert processing facility (e.g., System Center, OpenView) with fully
customizable alert processing and multiple notifi cation channels (e.g.,
pager, text messaging, e-mail, voice, etc.)
Report A scalable reporting engine having native data access and a robust set of
reporting features such as:
Tabular data display•
Sorting, fi ltering, and grouping•
Chart and graph generation•
Dashboarding•
Multiple export formats (e.g., Excel, PDF, HTML) •
TAF-K11348-10-0301-C007.indd 116TAF-K11348-10-0301-C007.indd 116 8/18/10 3:08:06 PM8/18/10 3:08:06 PM
Tactics: An Introduction ◾ 117
and deployment of controls. It is important to realize that in any given strategic planning cycle
you will have realized objectives, unrealized objectives, and emerging objectives. In other words,
depending on the resources, budget, and so on that you have available, you will reach some objec-
tives, others will not happen or will only be partially realized, and new objectives will crop up
that were not anticipated. A wise commander keeps an appropriate amount of resources in reserve
to deal with changes in the tactical requirements. ere are only so many ways a system can be
attacked; all tactics, off ensive or defensive, are based on this limitation. Understanding the limita-
tions of attack scenarios allows us to focus on the tactical principles that most effi ciently deal with
the threat. Tactics share a set of primary truths or “fi rst principles” that guide their development,
selection, and deployment. ese principles are an integral part of the tactical framework the
authors used to drive their selection and recommended uses of security tactics.
As we shall show, defense is a stronger form of fi ghting than attack.
Carl von Clausewitz
On War
TAF-K11348-10-0301-C007.indd 117TAF-K11348-10-0301-C007.indd 117 8/18/10 3:08:06 PM8/18/10 3:08:06 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.