230 ◾ Security Strategy: From Requirements to Reality
security products track malware outbreaks. Still others employ Honey Pot Systems to recon poten-
tial exploits and intrusions, and to capture malicious code for submission to antivirus vendors.
Honey Pots are basically decoy systems that conduct passive reconnaissance. When attacked, they
respond as a real system would, but in the background they are capturing information about the
attacker and the tools/exploits they are using.
Reconnaissance is one potential reason for hiring a hacker, although this has more to do with a
hacker’s social connections than it does with their technical skills. Someone who is an active mem-
ber of the hacker community has the ability to gather information about emerging exploits, tar-
geted systems, and hacking trends. is information can be used to facilitate preparedness through
the identifi cation of potential exploits and the deployment of appropriate countermeasures.
Assessment, hiring hackers to fi nd fl aws and potential exploits in your systems, is also a good
defensive tactic, especially for systems exposed to the Internet. Assessment eff orts include hiring
code reviewers and security testers during product development, as well as employing penetra-
tion testers when the original and subsequent revisions of the code are placed into production.
Microsoft’s Security Development Lifecycle (SDL) is a great example of this tactic. SDL incorpo-
rates a number of diff erent processes designed to improve the quality and security of code. e SDL
process includes security testing at multiple levels. Development teams perform regular security
testing during the development cycle, and the Secure Windows Initiative (SWI) team performs
additional testing when the product is code complete. When Microsoft built the initial SWI team,
it actively recruited a number of well-known security researchers to work on the team. While SWI
focuses on product security, other teams within the company manage SDL for programs used
internally and for customer-facing services, including Xbox Live, Microsoft Online, MSN, and
Microsoft.com. In addition to these code review and testing teams, Microsoft maintains its own
penetration test team and hires third parties to perform testing and product security reviews.
How to Use This Tactic for Defense
Hiring someone full time to perform defensive intelligence gathering is cost prohibitive for most
organizations, but there are a number of excellent subscription services such as the SANS Internet
Storm Center that provide excellent reconnaissance information. Source code reviews and pen-
etration testing services are readily available from a number of third-party fi rms, and the results
tend to be more comprehensive because of the breadth of experience of the people involved. e
exceptions to this rule would be government agencies and some larger enterprises. ese organi-
zations have the resources, time, and motivation needed to do in-house testing. Microsoft’s SWI
team is one example. Microsoft also maintains a reconnaissance capability through its relation-
ships with security researchers and hacker communities. In addition to cost, the time and eff ort
involved can be substantial. It is rumored that in addition to costing millions of dollars to perform
security reviews for Vista, the time those reviews took also contributed to the lengthy delay of its
initial release.
ere are also some real advantages to hiring hackers for certain types of security engagements.
For penetration testing, the real-world experience of a former hacker is particularly valuable.
Compromising the security of a system requires the application of multiple techniques. Books
can explain the techniques; real-world experience can apply them. Hackers are also very adept at
developing the tools required to exploit systems. Once, while doing a code review on a system,
Bill pointed out a potential security fl aw to a colleague (a former kernel developer for the Santa
Cruz Operation). In less than an hour, the developer generated the proof-of-concept code needed
to prove the fl aw was exploitable.
TAF-K11348-10-0301-C012.indd 230TAF-K11348-10-0301-C012.indd 230 8/18/10 3:11:56 PM8/18/10 3:11:56 PM
Keep Your Enemies Closer ◾ 231
SIDEBAR: SECUREPOINT HIRES A BLACK-HAT
Microsoft restricted its hiring for the Secure Windows Initiative to white-hat hackers, but in the past few years, a
number of companies have hired “reformed” black-hats to help improve the security of their products or to increase
the effectiveness of their services. SecurePoint’s hiring of Sven Jaschan (the confessed creator of the Sasser virus) is a
notable example. SecurePoint builds fi rewall appliances with antivirus and anti-spam capabilities; if SecurePoint’s
objective is to improve the effectiveness of their products, hiring someone credited with creating 70% of the world’s
viruses seems to be a reasonable course of action. Not every professional would agree, including the CEO of
H+BEDV who canceled the company’s partnership with SecurePoint the day they hired Jaschan.
Summary
e use of “hackers” within an IT security context is entirely dependent on the objectives you are
trying to achieve. e use of criminal agents (black-hats) is justifi ed only if your objectives are
clandestine in nature and the agents can be closely monitored to ensure their eff orts are not turned
inward. Clandestine activities tend to be off ensive in nature and support the tactical principles of
observation and preparedness. is activity also supports rapid response in the sense that it allows
a targeted entity to respond with equally devastating blows. Furthermore, this type of activity
involves a small force, concentrated on limited targets and usually not in harm’s way. On rare
occasions, the use of black-hats to improve the eff ectiveness of security products may be justifi ed,
but, in general, the use of criminal elements to protect information systems is discouraged. e
time, eff ort, or costs involved in clandestine activities is not a factor for government-sponsored
activities, but corporations need to weigh the cost and benefi ts before funding such eff orts.
Reconnaissance is probably the best benefi t of hiring a black-hat hacker, but expecting a black-hat
to do full-time reconnaissance is probably a little unrealistic.
e contrasting alternative is the use of security researchers, code reviewers, and penetration
testers (i.e., white-hats) to improve the defensive capabilities of systems and products. is is con-
sidered to be a sound practice. With the exception of organizations with a large Internet presence
or highly sensitive data, outsourced services seem to be the better and more cost-eff ective way to
accomplish these objectives.
Gray-hat hackers are an enigma. Although their intent is not malicious, some of their activities
are nonetheless criminal and could result in harm to the party they are purporting to help. e
level of trust you put in someone who is willing to break the law on the pretense that it achieves
a greater good is really a judgment call. Gray-hats also provide a reconnaissance benefi t because
of their reputation and contacts within the hacking community. Caution in hiring and a strong
monitoring program seem to be the best overall approach.
The Hire a Hacker Controversy
e main controversy in the industry surrounding the use of hackers is primarily related to the
question of trust. White-hat (ethical) hackers and security researchers are considered trustworthy
and smart hiring decisions. Hiring “reformed” black-hat hackers is generally considered unaccept-
able. For all practical purposes, you are hiring a former criminal to maintain the security of your
company’s or customer’s information. It’s hard to justify that thinking to your partners, customers,
and stakeholders unless you have an ironclad way to monitor exactly what that person is doing.
Mitnick Security Consulting serves as a good example. Here’s a security services organization
owned by a convicted hacker who, according to the company’s website, never did anything wrong
(or at least didn’t deserve to be convicted of doing anything wrong). e company off ers a large array
of security consulting services, but other than Kevin Mitnick’s experiences compromising system
TAF-K11348-10-0301-C012.indd 231TAF-K11348-10-0301-C012.indd 231 8/18/10 3:11:56 PM8/18/10 3:11:56 PM
232 ◾ Security Strategy: From Requirements to Reality
security, it’s diffi cult to understand how this organization has anything more to off er than those
staff ed by experienced white-hats. e question becomes one of trust. Which is more trustworthy,
a company run by a convicted criminal or a company run by certifi ed security professionals?
Misplaced trust can prove disastrous. e best way to deal with this risk is to have an ironclad
way to monitor what people are doing and to validate that those activities are appropriate for their
assigned duties. is includes technical activities, as well as personal behaviors such as moods,
attitudes, and interactions with other people. Ideally, this level of technical and supervisory moni-
toring should be standard practice for all employees because they all represent an insider threat.
When you hire a former black-hat, technical and supervisory monitoring is mandatory; unfortu-
nately many organization are not equipped to do this competently. is can be less of an issue if
the activities of the individual can be limited or isolated—for example, they do not have access to
internal systems or resources. Separation of duties is another alternative. In this scenario, a person
is not given enough authority to accomplish a high-risk transaction by themselves; rather, the
transaction requires the participation of another party to be completed.
Another potential challenge is connectivity. If your operations are designed to be clandestine,
it will be necessary to develop a means of hiding the identity of your organization and operatives.
is may involve the development of custom code or the engagement of external services. is is
equally true for some of the tools you may require for these activities.
Hiring gray-hats has its own challenges. How much trust can you put in someone who is will-
ing to break the law on the pretense that it achieves a greater good? Such logic is questionable at
best; it is seldom necessary to actually compromise a system to demonstrate that a fl aw exists. If
the goal is to be able to prove there is an exploitable fl aw, the better course would be to wait until
after you have notifi ed the system owner. If they don’t believe you, then you have an opportunity
to demonstrate the exploit to them. Take this scenario, for example: A gray-hat discovers a fl aw
in a system at a law fi rm. After compromising the system, he runs a directory listing of the fi les
he can access and sends it to one of the partners of the fi rm. When the partner looks at the list of
fi les, he comes unglued because this “well-intended” gray-hat has just compromised the integrity
of thousands of pieces of evidence!
Another consideration has to do with a person’s willingness to extend gray-hat logic beyond
information security. Suppose such a person discovered a business practice within the organization
that he considers “injurious” to the public. Could you trust this person to abide by the nondisclo-
sure agreement, when he is perfectly willing to violate the law for “the greater good”? Again, it is
hard to justify that thinking to your customers, stakeholders, and partners if you do not have a
strong way of monitoring their activities. (See Chapter 9 for further discussion on monitoring and
compliance.)
Another challenge to reconnaissance is corroborating the information gleaned from hacker
communities. e information may be incomplete, inaccurate, or overstated, making it diffi cult
to determine what, if any, response is needed and, if needed, what is appropriate. A similar issue
is true of any hacking tools sourced from a black-hat community; they must be checked for mali-
cious code before they can be used. If hackers are willing to put attack code on their websites, they
are certainly willing to put it in the software they build.
Trust is the main issue involved with the hiring of hackers. White-hat (ethical) hackers are
considered trustworthy, but “reformed” black-hat hackers are generally considered to be unwise
hires. As suggested earlier, it’s hard to justify hiring a former criminal to maintain the security
of your own or your customer’s information. is is equally true of gray-hats because of the
questionable logic behind breaking the law on the pretense of achieving a greater good. A high
level of technical and supervisory monitoring is the only sensible way to address these risks, but
TAF-K11348-10-0301-C012.indd 232TAF-K11348-10-0301-C012.indd 232 8/18/10 3:11:56 PM8/18/10 3:11:56 PM
Keep Your Enemies Closer ◾ 233
competence in these areas is lagging in many organizations. e reliability of the information
gathered from hacker communities is also of concern, as is the reliability of tools sourced from
black-hat sites.
Success Factors and Lessons Learned
Good intelligence, whether it is gathered for off ensive or defensive purposes, is complete and
accurate, and can be corroborated. is includes information about existing systems, products,
and services, as well as information about pending attacks and attack trends gathered from hacker
and nonhacker resources. e success factors aren’t that much diff erent for off ensive intelligence
gathering except for the stealth factor (not getting caught doing it) and the exploit factor (using
the information to successfully “acquire” an enemy resource).
Being able to fi x security fl aws in products and services before they become exploitable vulner-
abilities is an important cost-reduction measure in both patching and updating costs and liability
avoidance. It is also a major competitive advantage. Building products and taking steps to prepare
for and counter the next wave of attacks are other great results that can be realized from hiring a
hacker. Just remember, however: Misplaced trust can be disastrous if you are dealing with people
of questionable character.
e best lessons learned in this discussion are from Microsoft’s Secure Windows Initiative
(SWI). SWI is credited with fi nding and helping to fi x over 500 security fl aws in Microsoft
Windows products since its inception in 2004. Microsoft’s SDL process has reduced major vul-
nerabilities approximately 50% generation after generation of their product releases. One of the
most outstanding examples is the Internet Information Service, which has suff ered no signifi cant
security issues since the version 6 release. Much of this success can be credited to the outstanding
work of the SWI team of white-hats.
SIDEBAR: HIRED HACKER GONE BAD
Ethics appears to be the primary concern when the industry talks about hiring gray- and black-hats. Despite this
concern, the authors were unable in all our research for this book to fi nd any examples of a hired hacker gone bad.
That’s not to say it hasn’t happened, but just that we were never able to fi nd a news story or any article corroborat-
ing the notion that hiring a former gray- or black-hat to do security-related work represents an inordinate risk. In fact
the research is actually tilted in the other direction. National Infrastructure Advisory Council (NIAC) research into
employee screening practices concluded that the presence of a criminal history record was not in or of itself a clear
indicator of risk. NIAC did fi nd a consensus among experts that for some types of convictions broadly applicable
risks are present. However, “for other types of convictions, research on recidivism indicates that risk diminishes
with age and time.” In other words, the “I was a stupid kid” argument seems to have some merit. The NIAC report
also points out, “Currently, there is no research available that directly correlates criminal conviction history with
employee risk.” However, when combined with other factors such as a propensity for pushing boundaries, breaking
rules, substance abuse, and antisocial behavior, criminal history defi nitely contributes to the appraisal of someone’s
overall trustworthiness.
Control Objectives
ere are four primary risks associated with the hire-a-hacker tactic: malicious insider, target retali-
ation, target deception, and malicious code implantation. ese risks apply equally to the off ensive
and defensive elements, although the attributes may be slightly diff erent. e off ensive element
also carries with it a risk of being caught. In the government arena, this is the threat of diplomatic
or legislative repercussions. In the business world, it is the threat of criminal prosecution.
TAF-K11348-10-0301-C012.indd 233TAF-K11348-10-0301-C012.indd 233 8/18/10 3:11:56 PM8/18/10 3:11:56 PM
234 ◾ Security Strategy: From Requirements to Reality
Our defi nition of a malicious insider is based on the NIAC defi nition of insider threat. We
prefer the NIAC defi nition because it encompasses both IT and physical security. A malicious
insider is “someone with the access and/or inside knowledge of an organization that would allow
them to exploit the vulnerabilities of the entity’s security systems, services, products or facilities
with the intent to cause harm.” “Someone with access” encompasses current or former employees,
contractors, partners, and anyone else within the organization’s “circle of trust” that at some point
in time had legitimate access to these assets. Target retaliation is the threat of reprisal for your
off ensive actions against a target or for your deception in defensive actions. Target deception is
the reverse: e target attempts to bait you into some kind of action by appearing as something
it is not, feeding you phony or unreliable information or supplying you with bogus or malicious
software. e threat of malicious code is always a concern when dealing with black-hats. Drive-by
attacks when visiting hacker websites as well as malicious code in downloaded hacker tools are two
common methods used to implant malicious code on a system.
Countering Insider Threats (Malicious Insider)
e “insider threat” has been a major topic of discussion in the security community for a number
of years. Insider threat is a trust issue: People are entrusted with certain assets at the time they are
employed or associated with the fi rm. Diff erent degrees of trust exist based on the sensitivity or
value of accessible assets. Highly trusted individuals, such as system administrators, are given con-
trol over a broad spectrum of resources. When someone deliberately betrays that trust, the results
can be devastating to the organization, its employees, and its customers. Hiring someone with a
nefarious background only heightens the potential for malicious insider activity. While this is a
legitimate concern, insider threat extends beyond hacker hires; it applies to all employees because
all employees have the ability to commit malicious insider acts.
SIDEBAR: ROGUE ADMINISTRATOR
One of the most diffi cult situations for an organization to deal with is a rogue administrator. A few years ago the
company Bill worked for was called in to investigate an attempted compromise of an executive’s mailbox. No
data had been compromised; the real concern was who had gone bad. Either the administrator account had been
compromised or one of the 13 people in the organization who knew the administrator password had used that
knowledge to alter an e-mail security fi le. Based on the logs and fi le permissions, the latter was the more likely
scenario. As security professionals, the fi rst question that comes to mind is, why were they allowed to log on using
the administrator account in the fi rst place? That’s a good question, but it pales in comparison to, “Who can I no
longer trust?” Yes, best practice says to eliminate or very carefully control the use of the administrator account, and
going forward this would be the standard practice at this fi rm. But the question the IT director still had to deal with
was, “Who can I no longer trust?” We entrust our administrators with full access to our systems and system content;
when that trust is violated, it’s a devastatingly serious situation. Today it was a mailbox; tomorrow it could be all the
credit card records.
As security consultants, one of the oddest questions we get asked is, “How can I restrict admin-
istrator access to a system?” You can’t! is is why it’s called the administrator account. You can
change fi le permissions and encrypted data, and you can do any number of other things to try and
limit what the system administrator can access on a system, but at best it only slows the user up.
An all-powerful user has the ability to circumvent any control and to cover up the fact that he or
she did it. is is why a rogue administrator is such a serious problem: If you cannot trust your
administrators with the “keys to the kingdom,” who can you trust?
ere doesn’t seem to be a consensus on the percentage of attacks that are insider driven
(estimates range from 20 to 80%), but there is no doubt that insider attacks do the most damage.
TAF-K11348-10-0301-C012.indd 234TAF-K11348-10-0301-C012.indd 234 8/18/10 3:11:56 PM8/18/10 3:11:56 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.