Most organizations are going to experience a computer security incident each year. Those organizations that don’t experience an incident only avoid doing so by being blind to what is going on in their information systems. If you are even casually looking at your computers and networks, you will find incidents. At the very least someone is going to plug an infected USB device they received as a Christmas/birthday present into their work computer. At worst, an attacker is going to be rummaging around on your internal network. Most organizations are going to experience something in between those two extremes, like a “drive by” web attack on an unsuspecting user who was searching Google for a good deal on Chuck Taylors. It’s going to happen. Accept it.

Now that you’ve accepted that it’s going to happen, you better be prepared to handle the situation. How you react depends on the criticality of the information stored on the compromised system(s) or network(s). If your CEO’s administrative assistant gets malware on his/her computer, but the only access they have is to the Internet, then your response is pretty easy: clean the machine or reinstall it from a clean image. Done. If your accountant’s computer gets malware, then you have some bigger issues. You’re going to need to do some research to see if any of your accounting data has been exfiltrated, including, perhaps, account numbers of your business partners or customers. That would be bad.

The point is that you need to have a plan on how to escalate the handling of the incident. Do you pull compromised machines off the network immediately? Who gets involved, and when? Who makes those hard decisions like shutting down the compromised database server that powers your e-commerce website? Every organization needs to at least have a start at outlining this process. You’re also going to need to have a general idea of where your data rests, and how critical that data is.

If you wait until your first incident to start thinking about this, you’re response is pretty much guaranteed to fail. So start now. NIST has produced a document, SP800-61, that goes into some depth about incident response plans and procedures. While following that document is going to be overkill for small organizations, at least having a familiarity with it will help you in writing your own basic incident response plan.

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

The latest Microsoft Security Intelligence Report (Volume 11) has been released and contains some interesting information that Microsoft has collected from the execution of its Malicious Software Removal Tool (MSRT) and Internet Explorer SmartScreen® data.  Several of the results confirm what those of us in the network security monitoring community already know: Java is the most often exploited application (page xvii), Adobe Acrobat exploits account for most malicious documents (page xviii), and Adware is the most common type of malware identified (page xx).  Microsoft also stated that over a third of malware detected could spread via the AutoRun feature on removable media or on network shares.  Updates exist that help make the AutoRun feature in XP and Vista more like the one in Windows 7, which is to say more secure.  Deploy those updates.

Some of the more interesting information reported:

• What is not getting exploited as often as I would have suspected – Adobe Flash and Microsoft Office.  Even though two Flash vulnerabilities identified in the first half of 2011 led to an increase in exploits against Flash, Flash is getting exploited 7 times less often than Java!

• For the last four quarters (Q3 2010 through Q2 2011) the detection of trojan and backdoor malware has experienced a consistent slight downward trend.  An explanation could be the coordinated take down of several large botnets in the past year.  Microsoft has been involved in those take downs, so a shout of thanks goes to them!

• Another unexpected result: phishing attacks against social networks accounted for slightly less than half of all phishing attempts, while attacks against financial institutions accounted for slightly more than one-third of phishing attempts.  In April, Microsoft’s data indicated that 84% of all phishing attempts were against social networks.

So, what does this mean for security professionals in the corporate world?  Well, it’s nothing new really: protect the clients just as you would the servers.  Patching the OS is no longer enough.  You must patch applications regularly too – most importantly, Java, Acrobat, and Flash.   Disable AutoRun, if possible, but at a minimum deploy the updates from Microsoft for XP and Vista that make them more secure.  And, finally, warn your users about phishing attacks and discourage using the same password for personal social networking and financial websites as they use for their corporate login(s).

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

The results of the investigation into the recent DigiNotar SSL CA breach reads like a laundry list of “Things Not To Do™” on your critical servers and networks: no antivirus, no centralized logging, and outdated/vulnerable software exposed to the Internet, among other items.  What’s funny about the above list is that if the breached systems had been part of DigiNotar’s PCI cardholder data environment, then DigiNotar could never have passed a PCI QSA audit as all three items I noted above are required by the PCI DSS.  While I couldn’t verify that DigiNotar accepts credit card payments for its SSL certificates, it almost assuredly does (or did!).  It almost certainly had undergone a PCI QSA audit, too.

What are we to conclude from this information?  If my preceding two assumptions are true, then it would appear that DigiNotar likely protected its servers and networks involved in accepting and processing credit card transactions better than it protected the servers and networks involved in generating SSL certificates.

There is no reason not to have antivirus loaded on every server and workstation and no reason not to conduct regular vulnerability scans of your external services in an effort to identify vulnerable software.  For medium-sized businesses (50 or more users, 2 or more IT guys) there should be one person in IT who is designated to watch vendor software websites for security announcements and new releases for all software in use that is exposed to the Internet.  The organization should be committed to at least protecting the external services, even if it can’t spare the resources to perform the same on the internal network.

On to the central point of this blog post: Centralized Logging.  This area is where things get a bit more involved and difficult.  It is not too hard to purchase and setup a machine with 1TB of drive space that could adequately serve as a collector of logging data.  It is also not too difficult to setup most common systems (switches, routers, firewalls, and Windows and Unix servers) to log to this system.  Where the difficulty lies is making that data useful in near-real time, rather than as a source of information after a breach.  To make that data useful you will need an event correlator, which is usually part of a larger service called SIEM (Security Information and Event Management).  To date, I have not been made aware of any SIEM products that are affordable to purchase for most small businesses.  And, that is to say nothing of the cost in personnel time to properly wield such a product.   From what I have seen, the open-source SIEM products are even harder to configure and use than the commercial products, so I can’t recommend any free (or low-cost) alternatives.

So, what is a smaller sized company to do?  That’s a good question.  If you can afford an SIEM product, buy one and pay a Managed Security Services Provider (MSSP) (like True!) to setup and manage the device.  If you can’t afford a full SIEM product, at least purchase an inexpensive server with two 1TB drives, install Ubuntu, put the drives in a software RAID-1 configuration, and setup a syslog daemon (Syslog-ng is perfect) to collect logs from the network.  At least if you are breached you (or the investigator you hire–True!) have a lot more information at your disposal to determine the extent of the breach.

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

In a previous article, I mentioned two firewall rules that every network should have: blocking outbound DNS (udp/53 and tcp/53), and blocking outbound SMTP (tcp/25). I’d like to suggest a few more rules to add to that list.

The first rule to add is blocking of outbound Windows NetBIOS/SMB/RPC requests. Windows networking requests should never, never, NEVER leave an internal network. Period. If you have a situation where you need to communicate with an external IP using Windows networking, I have two suggestions for you:

1. find another way to accomplish your goal, because the way you are doing it isn’t correct; or
2. setup a VPN connection to the external IP and force the requests to cross the VPN tunnel.

By blocking NetBIOS/SMB/RPC, you will prevent your internal systems from connecting to potentially malicious external hosts. Malware often attempts to initiate NetBIOS/SMB connections. Malware is bad. Go block the following services outbound:

• tcp/135
• tcp/139
• tcp/445
• udp/137
• udp/138

My next rule suggestion is kind of cheating, because I’m going to suggest a rule to supersede the previous three: block all outbound TCP and UDP traffic between ports 0 and 1024 (and consider blocking all ports up to 65535). This moves toward implementing the theory of “default deny”. Just as the default is deny for inbound traffic with specific exceptions, the default should be deny for outbound traffic with only specific exceptions. Then you can permit the services that should be allowed outbound, and while doing that you can write business justifications for allowing the traffic. Here are some suggested exceptions for an outbound default deny:

1. HTTP traffic (tcp/80)
2. HTTPS traffic (tcp/443)
3. FTP traffic (tcp/21)

And then some optional rules, if policy permits:

4. External e-mail services: POP, POP/SSL, IMAP, IMAP/SSL, and Message Submission (tcp/110, tcp/995, tcp/143, tcp/993, and tcp/587, respectively)
5. Adobe Flash Real-time Streaming Protocol (RTSP) (tcp/1935)

Even better than a default deny with explicit exceptions, start employing a web proxy (a topic for another post).

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

As you may know, our company provides 24×7 Network Security Monitoring services to many customers.  Our clients vary widely in size, industry, and information security maturity.   Even so, we see many similar successes, failures, and trends in security monitoring alerts between these customers.  Spyware infections tendsto be a significant number of the incident reports we generate.  Today, I would like to write about the reason spyware alerts are a threat to your organization, why you should take them seriously and respond timely, and what you can do to decrease these incidents on your network.

The danger of spyware is two-fold.   First, it indicates a deficiency on the part of the user in general information security knowledge and specific corporate information security policies.  A spyware infection means that the user likely installed unapproved software on his/her system.  Perhaps the user was doing non-business related web surfing and found the “Totally Awesome Change Your Life Toolbar” from hAcme Software, Inc.  Or maybe the user was tricked into installing this software via social engineering.  (“Click here to install a media player to see Jane E. Celebrity in a bikini!”)  Either way, the user was not aware of the dangers of his/her actions wrt. information security and wrt. corporate security policies.  (You do have policies defining acceptable use of corporate information resources and punishment for misuse, right?)

The second danger (related to the first–in fact, the first is a consequence of the second, so maybe I should have reversed these points–oh well) indicated by a spyware infection is that the user has sufficient rights to execute unapproved software on his/her system that can modify his/her settings and hijack information.  With these rights the user may be delivered and subsequently execute much more damaging malware that exfiltrates personal and/or corporate information or receives and executes instructions from external attackers.  This malware may be delivered by the spyware itself.  Regardless of how it is delivered, your organization has a problem, and it needs to be fixed.

For these two reasons above you should take spyware infections seriously and respond to them in a timely manner.  But what can you do to limit future infections?

1. Limit user rights.  Do not make them a member of the local Administrator or Power Users groups.  If you have applications that require Administrator privileges to run (QuickBooks, I’m looking in your diretion), get rid of them.  That is a poorly designed application and is likely going to have far worse flaws.
2. One word: Education.  Provide it to your users.  If you don’t have a sufficiently trained and knowledgeable employee who can teach one day classes on information security, there are plenty of companies that provide that service–and you won’t have to develop the curriculum.  Google is your friend, here.
3. Follow the hardening guidelines from Microsoft, NIST and NSA on how to secure your Windows systems and networks.
4. Use Group Policy or other enforcement mechanisms available from companies like Cisco, Symantec, etc., to whitelist applications.  Only applications listed in the whitelist can be executed by the user. Use Group Policy to disable all but a few approved Internet Explorer BHOs (Browser Helper Objects).  This will prevent a lot of the toolbar spyware software from infecting your systems.
5. Get serious about your corporate information security posture.  Convince upper management to dedicate sufficient time and money to sustaining a CISO position.

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

The Verizon Business RISK Team released a very interesting study early in June with detailed results and analysis from more than 500 forensic investigations it conducted over a four-year period (2004 to 2007). It claims that this study represents one-fourth of all publicly disclosed data breaches in that time frame. The report is chock full of statistics and percentages. The study examines the age-old question of IT risk-management: who is the largest threat source, insiders or outsiders?

The study weighs the impact of breaches (number of data records compromised) along with the frequency of threat source causing the breach. It also adds a third threat source to the mix: business partners, a sort of blended insider/outsider. One of the interesting results is that, using the classic risk equation (risk = likelihood * impact), business partners represent the greatest threat, followed closely by insiders.

The paper presents statistics but makes no blanket-conclusions on what to do about the problems, instead leaving that up to the individual organization (as it should). Everyone knows that monitoring the insider threat is difficult and time-consuming. It is somewhat easier to monitor business partners since they (should) have limited access via well-defined conduits. Given the results of this study, monitoring business partner interaction with the corporate network data sources may become the new fad in IT risk-management.

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

I have spent a fair amount of time over the last several months analyzing the Security Information Management (SIM) market to see how products like Arcsight[arcsight.com], QRadar[q1labs.com], SecureVue[eiqnetworks.com], and enVision[rsa.com], could benefit us (and our customers) as a Managed Security Service Provider (MSSP)[truedigitalsecurity.com]. I was intrigued, then, when I picked up the December issue of The ISSA Journal and saw an article entitled, “Logs Do Not Lie.”

While there are many advertised benefits to SIM solutions (log management, forensics, threat management, compliance, etc.), one of the take-aways I had from this article regarding the benefits of using a SIM solution was the idea that authorized activity is not always the same thing as safe or legitimate activity.

The two examples provided by the article to illustrate this point involve website mirroring and file transfers. Website mirroring looks a lot like regular web browsing, except it is usually complete (every page is visited) and the pages are viewed in rapid succession. Firewalls and web servers typically log traffic suspected of mirroring the site, but it is not usually treated as actionable information because it is so similar to legitimate activity. Website mirroring is interesting, however, because it could be a precursor to a phishing attack, especially if the source of the mirroring is not a regular client or is located in an interesting geographic region.

The file transfer example is related to Network Behavior Anomaly Detection (NBAD), a feature provided in one form or another by many SIM products. The idea with this illustration is that a given network user may routinely transfer information via external File Transfer Protocol (FTP) servers. If, however, this user’s typical exchanges are around 10K and a 600M exchange is identified, it is noteworthy and probably merits further investigation.

Both examples illustrate the value in collecting information from the various sources on your network (routers, firewalls, servers, IDSs, etc.) in order to analyze and report on that information. Judging by the customer lists on the SIM vendor websites, it would appear that there are quite a few organizations already seeking to take advantage of this information.

Dominic Schulte

Dominic Schulte currently serves as the Managing Director of Security Services & Consulting at TRUE, where he is responsible for the execution of a wide range of security and regulatory compliance services. Previously, Dominic worked with the National Security Agency (NSA) as a Global Network Exploitation and Vulnerability Analyst in the National Security Incident and Response Center (NSIRC). He holds CISSP, QSA and CNSS 4011-4015 certifications.