250 ◾ Security Strategy: From Requirements to Reality
Malware Protected
Malware can be detected in multiple ways beginning with the content of the code (signature rec-
ognition), the behavior of the code (behavior recognition), or the results of the code’s execution
(modifi ed fi les, running processes, open ports, etc.). Since the goal is containment, not prevention,
tools that scan content need to be confi gured to quarantine not “clean” or reject malicious code.
Behavior controls need to be confi gured to block potentially dangerous behaviors (e.g., attempting
to modify a system fi le or confi guration), and result-based tools need to be confi gured to detect
anything that slipped through the previous two controls. Look for single-purpose, effi cient, and
accurate signature-based scanners. With over 2 million malware signatures to check, effi ciency is
critical. e same thing goes for behavior controls. You’re looking for a self-contained, accurate
intrusion prevent agent—in other words, something that works without a separate control console
and does a good job of blocking bad behaviors. Finally, use tools that do a comprehensive job
detecting unauthorized changes to fi les (i.e., Tripwire), as well as tools that can accurately detect
running instances of malware, including root kits.
Privilege Restricted/Execution Restricted
e best privilege restriction is no privilege. Microsoft has an add-in for Windows (AppSec) that
controls application execution. It can be somewhat challenging to use if you have a lot of scripts
and external tools, but there is no better mechanism to prevent downloaded malware from doing
damage. Sandbox solutions are the next best mechanisms; Java and DotNET have confi gurable
privileges (permissions) controlling what executed code inside the sandbox is allowed to do. Vista
and subsequent versions of Microsoft operating systems also have an integrity control that pre-
vents downloaded code from accessing and modifying other fi les or system confi gurations.
Scanned
Any compile code (binaries) acquired from any external source should be subject to malware
scanning by three separate scanning engines. E-mail scanning products typically use three out of
a selection of fi ve scanning engines to check messages and attachments for malware. If you don’t
have a separate system you can set up for scanning, you may be able to get the same results by
attaching the code to an e-mail message and sending it to yourself. If the message loops through
the mail system, chances are the code is clean, or at least free of any known malware.
Execution Reviewed
When source code is not available, it is prudent to perform an execution review of the code. An
execution review captures the fi les and confi guration data the program accesses, as well as any net-
work traffi c it generates. Reviewing the captured data can reveal suspicious or dangerous behav-
iors, for example, attempting to contact an external website. A good network sniff er is suffi cient
for the network capture; capturing fi le and confi guration activities are platform specifi c, but good
tools are available for most popular operating systems.
Code Reviewed
e preferred format for all tools acquired externally is source code. We are not saying it’s impos-
sible to hide malicious code in source code, but it’s certainly a lot more diffi cult and it’s nearly
TAF-K11348-10-0301-C012.indd 250TAF-K11348-10-0301-C012.indd 250 8/18/10 3:11:57 PM8/18/10 3:11:57 PM
Keep Your Enemies Closer ◾ 251
impossible to hide from a skilled code reviewer. Code reviews are your best defense against
logic bombs, backdoors, and other types of malicious code in tools you acquire from black-hat
resources—so much so that we recommend decompiling binaries and reviewing the resulting
source code if source code is not available for a particular tool. e issue involved in doing code
reviews is usually one of resourcing. Code reviews are tedious and time consuming and require a
rather sophisticated set of skills, so there is a trade-off . Smaller utilities and tools should be source
code reviewed. For larger applications, an execution review combined with other mitigation con-
trols such as sandboxing and IPS may prove to be more cost eff ective.
e following actions are recommended for the malicious content implantation control
objective:
1. Identify resources that can assist with code reviews and tool evaluations.
2. Develop appropriate procedures for dealing with malicious content to ensure that it is at all
times contained to include management and custody controls for all media containing mali-
cious code.
3. Gather and test the recommended best practices for high security hardening of the plat-
forms you are using for reconnaissance.
4. Determine the equipment and resources required to set up an isolated reconnaissance capa-
bility, including capital and run expense estimates.
5. Acquire and test potential security controls for malicious content, behavior, or results detection.
6. Acquire and test system recovery or rebuild tools that permit quick recovery from a system
that has been compromised.
Conclusion
is chapter covered two important personnel-related tactics. e fi rst, hire a hacker, discussed
the merits of hiring clever people to assess security controls, improve security products, and recon
future threats or exploits. e second tactic, countering insider threats, discussed control objectives
for mitigating risks associated with malicious insider activities. e use of “hackers” in the context
of IT security is entirely dependent on the objectives the organization is trying to achieve. e
use of white-hats to improve the security function of your products and service is a good practice.
Security professionals generally consider employing “reformed” black-hat hackers to be a bad idea,
although there doesn’t appear to be any body of evidence to support the notion that this practice
substantially increases risk. In truth, all employees have the potential to commit malicious acts,
and insiders typically will do three times the damage that an external attacker might do.
Malicious insiders have authorized access that bypasses most network and host-based controls;
weaknesses in operating system and applications controls exacerbate the problem by granting
users access to inordinate amounts of data. Management complacency, corporate culture, empow-
erment, erratic enforcement, and missing supervisor skills also add to the problem. Company
processes, including audit, hiring, and termination practices, supervisory controls, and incident
response, are often inept and require technologies to manage user identities, collate physical and
logical accesses, and detect unauthorized activities. e problem is systemic; the industry is just
now starting to recognize the tremendous risk that insider malfeasance represents to companies,
agencies, and the public. is isn’t a hired hacker problem; it’s an “everybody problem,” and until
technology catches up with the need, the best mitigation we have at hand is competent supervi-
sion: Nurture and promote it.
TAF-K11348-10-0301-C012.indd 251TAF-K11348-10-0301-C012.indd 251 8/18/10 3:11:57 PM8/18/10 3:11:57 PM
TAF-K11348-10-0301-C012.indd 252TAF-K11348-10-0301-C012.indd 252 8/18/10 3:11:57 PM8/18/10 3:11:57 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.