As this report covers cases between 2004 and 2007, an alternate method was necessary to compile statistics on
historical cases. Two primary methods were employed to collect the data presented in this report. Case files and
notes, being the most objective source of information, were the preferred method and were referenced if within
retention limits. Even when original reports were available, interviews with case investigators provided a wealth of
supplemental data and insight for this study and were absolutely crucial when the former sources were unavailable.

The report shed light on how security incidents is actually conducted. Here’s some conclusions:

• Incidents usually happens from the outside (73%), not the inside. Customers should be worried about their partners since they are one of the most frequent sources of attacks. Of all internal parties, IT-admins and ordinary employees are the most scary. Everyone is possibly malicous. Monitor your assets independent of whom the source is.
• Incidents happens equally often at small, medium and large size companies. Anyone with valuables are of interest. Security is important for all sizes.
• Incidents are results of hacking, but not all incororates malicious code or exploit vulnerabilities. Exploiting errors of various kinds are almost always a part of the success. Configuration management, system hardening and security monitoring is important since they are not focused on vulnerabilities and exploits.
• Incidents are usually results from exploiting the application layer, OS and sometimes a back-door. Attacks often exploits known vulnerabilities. Typical intrusion detection have problems with the application layer. Security monitoring shouldn’t be limited to the network layer.????
• Incidents usually requires little effort and have low difficulty (52%). Some incidents required a sophisticated hacker. Problem is, are the sophisticated incidents even detected as of today? They might not be in the report?
• Incidents are usually oportunistic, but sometimes targeted. This means that attackers seek vulnerable parties, not vulnerabilities at perticular parties. Or are incidents that are targeted yet undetected and not in the report?
• Remote Access systems and Web Applications are the primary entry points and attack paths. Limit their exposure by system hardening and segmentation and monitor the paths that are left exposed.
• Information is usually compromised in online, stored form, not from End user devices. Payment and PII-information are the types of information most frequently compromised. Control and monitor the assets.
• It usually takes an hacker minutes or hours to compromise a system, not seconds or days. We have time to detect them and respond to them. We don’t have to prevent them in real time (which rarely works), we have plenty of time to detect and respond to them.
• Incidents usually remains undetected for months.
• It usually takes the targeted company weeks to respond to the incident.
• Companies usually get to know of the incidents through third parties, or by an employee but not by their equipment. This means that few parties does detection right. I suspect most companies focus on technology that does prevention, then when they fail they get penetrated and have no idea about it.

A very good report.

Preventive controls reduce exposure. These are the controls that reduces attack surface and possible vulnerabilities. System hardening (e.g. disabling services and applications) and??segmentation (e.g. using router or firewall ACL:s) are example of preventive controls. Preventive controls acts before the attack by disallowing or making interactions with the target impossible. Preventive control are the most cost effective of all controls.

Deterrent controls reduce the likelihood of an attack. These are the controls or mechanisms that somehow makes the act of exploiting the target more difficult or unattractive, but not impossible. An example of a deterrent control are anything that actively discourages a party to commit something malicious, e.g. awareness and accountability efforts. I argue that an IPS is an deterrent control, because the asset remains vulnerable and can still be exploited. It only reduces likelyhood, not possibility. Deterrent controls may act before the attack when they aim to discourage, but also during the when the control actively try to deterr an ongoing attack.

Corrective controls reduces impact. Examples are systems that try to mimimise the damage from a situation. Examples are systems that quarantines systems, users or applications when certain conditions apply to them, or anti-virus systems that automatically tries to remove malware infected items that allready have precense on the system. Incident response and forensics is also a corrective control. Corrective controls act during or after an attack.

Detective controls discover security issues and conserns. Detective controls creates visibility and reduces uncertainty.?? Examples of detective controls is performing log analysis and deploying sensors that actively looks for indications of attacks, and vulnerability assessment solutions that bring insight into where vulnerabilites are present.??Detective controls are necessary for deterrent and corrective controls to work. I believe this control is best implemented by performing security monitoring.

I believe these are good components of a defense in depth strategy, together with the ordinary network, host and application idea. I also think this captures the importance of monitoring and response, and the problem of determining the value of deterrent controls.

I believe paramount to why this works in the analog world, is because incidents are naturally detectable. If someone steals your juwelery you’ll eventually miss it. We know how much the loss cost, and since all of us have insurance we (or at least the insurance companies) have good averages on what a normal person is likely to loose per year and bases their premiums on that.

But a digital asset can be stolen in a number of ways without the owner knowing about it. Digital incidents aren’t naturally detectable, and we have no real numbers on the number of incidents and the average costs associated with them. In fact, there are insurances for digital security breaches and issues, but if we fail to detect them, when are we ever going to make us of our insurance? It will never be the most cost effective method. It seems like we have no option other than employing prevention and chasing vulnerabilities. But then again, since there are no perfect security, this approach will always leave us with an inaccurate view of incidents and no other options. Just another hamster wheel of pain. Find vulnerability, Patch and Proceed.

Security Events

Security events are any form of warnings, or what I like to treat them as, “indications” of attacks and/or malicious activities. From a security monitoring perspective, these events can direct the analysis and response activities in a direction where it is likely that something security relevant is happening. Security events can be an IDS/IPS alert from triggered signatures indicating that someone is targeting exploits at our public web services, or a network traffic anomaly alert indicating that an unusual high amount of traffic is leaving our network in the middle of the night. Security events need not be limited to digital ones, but can also be a user calling the help desk saying that his/her computer is slow.

Typical information sources are network/host intrusion detection/prevention systems, web proxies with malware features, endpoint antivirus systems etc. Any system that “looks” for attacks.

Communication Events

Communication events are anything that tell us who is talking to who. Collecting these events allows for establishing, depending on the type events of course, granular “audit trails”. A complete picture of how a certain host has been communicating can assist the response process by limiting the scope of a possible compromise, or to completely dismiss alerts in the case no traffic or data has been exchanged between the target and the source.

Typical information sources for informing us about communication patterns are Firewalls in the forms of Accept and Deny events; and Routing and Switching infrastructure by exporting meta data about sessions and traffic in the form of traffic flow information (i.e. netflow, sflow etc). Session data and network traffic flow information is favourable before firewalls. The ultimate information source for Communication Events are systems dedicated to sampling of full content data from traffic at strategic positions in the network. Full content data offers complete transaction records of sampled traffic, and can often completely verify or dismiss a suspected attack (unless it’s encrypted), but at the cost of alot of diskspace.

Identity Events

Identity events are any form of event that ties an IP-adress to another type of identity, i.e. a user name, a mac adress, a dns-name, a physical location such as a room-numer, or even a telephone number or in the case of an external host complete whois and owner/abuse information. Identitity events allows for establishing relationships between different identities and assets. A relationsship between an IP-adress and a Username aids the analysis and response process by making it possible to ask questions to the person in question.

Typical information source for Identity events are ordinary clients and servers, central authentication systems, dhcp server and dns server.

Activity Events

Activity events are information about activities, and not necessarily strictly security related ones. If communication events informs about who is talking to who, activity events informs about what they are saying and what they are talking about. Activity events allows us to know what is happening in a given situation/session/point in time - i.e. what actions hosts, users or processes are making. Having a complete picture of the HTTP requests a client have been making towards the internet can support the reponse of a possible malware infection of a client. Having a complete picture of what the IIS- and SQL server are up to eases the investigation of a possible XSS or SQL-injection attack.

Typical informations sources for Activity events are any strategic system that has a certain service. Web Proxies tracks any web requests to the internet. A web server, or a web application firewall, tracks interactions with the web server. Collecting Event logs from a Windows server or syslog feeds from an important Solaris servers allow you to track interactions with those resources.

To summarise:

Security Events point us to likely malicious activity. Communication events tells us who is talking to who. Identity Events tells us who the source and target is and Activity events tells us what actions a system, a users or a process is doing. My experience tells me that a successfull security monitoring requires a degree of all four of these.

• Evaluating cyber-attack incident data averages over time.
• Measuring the reduction of incidents from implementing new security programs.
• Valuating the impact of avoided incidents.
• Applying the results to similar areas to estimate future value.

The first step involves comparing incident counts between different months, years etc. Security is about avoiding bad things to happen, so a decrease of bad things happening must mean progress. Well, that is only true if we have an accurate value of the number of incidents. Our method of detecting incidents must be exactly as effective and accurate as last year, even though threats targeting us, vulnerabilities in our defences and assets of importance might have completely changed. If our defences (more specifically the detection process) doesn’t follow this change, we will have a inaccurate value of the number of incidents. Without measuring the accuracy of the detection process the “Number of Incidents” comparison is irrelevant. It becomes an oxomoron??where we are measurably secure while being insecure.

The “number of incidents” dilemma also haunts the second step which involves measuring the reduction of incidents from implementing new security investments (technical, processes, people etc). So if we make an investment and our incident count drops then that’s considered a success, right? What if that security investment causes incidents to go undetected? Perhaps turning on IPSEC between all our servers and clients are considered a security investment - but what happened with all the alerts from IDSs that contributed to defining incidents when all traffic flyes by encrypted? Again, the model must take detection accuracy as a parameter.

The second and third step involves “valuing impact of avoided incidents” and “estimate future value” of investments. These steps aim to define how much the investments have really paid of in terms of loss avoidance.??But seriously, how do you define the cost coming from an incident when it has not yet happend? Take a malware infection as an example: you can define the??potential??loss to be anything from??the consumption of 10% cpu and memory at an individual workstation to information disclosure and theft of scetches for the next stealh aircraft. This calculation allows anyone to creatively come up with numbers that are favorable for the situation.

Measuring??security progress and how security investments actually pays of is??an excellent idea. But it’s difficult??since both good and bad security might equal??zero incidents.??Somehow??we must also measure??how well we detect??incidents and malicious activity.??

Related to our lack of information on what is really going on out there:

“We recommend that the EU introduce a comprehensive security-breach notification law.”

“We recommend that the Commission (or the European Central Bank) regulate to ensure the publication of robust loss statistics for electronic crime.”

How else are we going to get a good picture of what is actually happening to others and how much it has cost them? My experience says that companies are getting really tired at hearing fictional stories and FUD. We need this.

Related to our inability of acting on issues:

“We recommend that the European Union introduce a statutory scale of damages against ISPs that do not respond promptly to requests for the removal of compromised machines, coupled with a right for users to have disconnected machines reconnected if they assume full liability.”

Internet have no boundaries.??If a computer or network in Sweden is compromised and maliciously managed from Poland their respective ISP need to be responsible for disconnecting that machine and be held liable if they don’t. Our laws need teeth.

Related to vulnerabilities and patches:

“We recommend that the EU adopt a combination of early responsible vulnerability disclosure and vendor liability for unpatched software to speed the patch-development cycle.”

“We recommend security patches be offered for free, and that patches be kept separate from feature updates.”

Without a proper picture of where our vulnerabilities are, how are we supposed to be able to define our risk? Before the patch is available, how are we supposed to be able to counter a specific vulnerability with a countermeasure? A law that requires vendors to quickly notify their customers and the public about a vulnerability will allow companies to make the strategic decisions that is necessary. And of course patches should be free.

Last but not least, we need to collaborate on cybercrime.

“We recommend the establishment of an EU-wide body charged with facilitating international co-operation on cyber crime, using NATO as a model.”

Incidents happends to everyone, it’s just a question of when. Therefor, every company needs to plan for Incident Response. So does??every nation and union.

Kudos to Enisa for a good report.

The most obvious peril hypervisors pose to virtualized network security is simply that they take that network traffic out of the range of conventional security devices. A packet sniffing appliance can’t see packets that never leave a given physical server. V-Agent solves that problem by residing within the virtualized network. It’s a logical approach to the problem.

V-agent by Catbird????is essentially a guest system - “a virtual security appliance” - that attatches itself and runs in the virtual network provided by the host (i.e. VMWare ESX) to virtual machines.??V-agent then monitors and filters traffic between other guest system as a traditional IPS.??Other functionallities provided by??V-agent are??NAC-like features??for??limiting the possibilties of accidently publishing??guest systems, and protection of the “hypervisor”.

This is interesting, because virtualisation certainly twists the concept of the “network”. The cloud becomes even cloudier, so to speak. But virtual systems and??guest machines are still essentially the same old Windows and Unix systems, and they use the same ways of communications as they always have. What is it to say that traditional solutions won’t work? They might just have to become a bit virtual?

Related to that, a year ago (2006) the Swedish government arm KBM published a report that highligheted the current state of Swedish cyber security efforts. From the report (”freely” translated),

It can be established that Sweden today lack a national system for discovering, alerting, terminating and in a coordinated way respond to [incidents].

Hopefully, the “requirements” mentioned in the debate will attempt to address this. Efforts such as giving SITIC - the national incident response organistation - additional funding and more responsibilities are excellent steps in the right direction. Other countries are also moving in this direction, such as the US for instance whom are currently planning to reduce the number of internet connections to be able to monitor them more efficently. I’d like to see Sweden following similar tactics.

In an attempt to make an example, have a look at authentication systems. Most of us understand that all passwords can be broken if the necessary time and resources are put into it. The security of the authentication system relies on the strength of passwords, and in order to higher the bar for brute forcing it we

• create a basic policy that defines the minimum strength of the password (eight chars, with numbers etc).
• we force the user to change the password every four, six or eight weeks.
• we only let the user make three unsuccessfull attempts before disallowing any further attempts (or we incrementaly increase the delay between each possible attempt).

The first two points are vulnerability oriented, meaning they attempt to increase the strength of the password and as such decrease the vulnerability of the password. They increase the level of effort the threat must put into brute forcing the password. The last one, however, focuses on preventing any attempts of guessing the password. It doesn’t increase the strength of the password, but drastically limits the threats possibility to repeatably try passwords. This measure is threat oriented and no matter how much money or time he or she puts into buying equipment for crunching numbers, all they have is three attempts (there are other ways of defeating authentication systems though).

This kind of threat centric approach is what most Intrusion Prevention technologies lack. Common IPS:s functions as authentication systems without the threat centric part; They block individual attacks but passively lets the intruder keep trying until he crafts an exploit that slips through. Good examples are solutions that correlates alerts with vulnerability information of the target (which ISS does) in order to decide what to block. They forget to question whether the activity itself is acceptable. Just because the webserver runs Apache, all attempts at exploiting it as an IIS is ok? Or just because a perticular vulnerability isn’t present in this version of Apache, the activity is ok? This kind of thinking is, for example, what causes IPS implementation to fail at repelling penetration tests.

To be fair, some IPS:s have the necessary functionallity for being a threat centric tool. Juniper, for instance, has the option to block individual offending packets, an offending session and ultimately an offending IP for a configurable amount of time. Other IPS:s has similar functionality. Problem is that the functionallity isn’t used in an automated fashion due to the risk of consequences from creating long lasting blocks of legitimate traffic sources. This is why I advocate the involvement of a human to make the ultimate decision to block an offending IP for a given time, or use a good SIEM system (Security Information and Event Management) that correlates alerts with other information sources to get the knowledge of context necessary to make accurate decisions.

Expect to see more posts related to threat centric security in the future.

“people spend too much time trying to reduce uncertainty and too little time focusing on reducing risk.”

My impression is the exact opposite. Companies spend to much time (and money!) on ad-hoc attempts in reducing risk with no control of where their biggest risks are or how these countermeasures actually pays of in terms of risk reduction. There is too much focus on headline-threats and efforts resembling “fire-fighting” and “socker-goal security”. Companies buy firewalls, intrusion prevention systems, data leak prevention solutions for millions so the can put them into place and forget them. There is too much uncertainty in daily security operations, which is why I think that reducing uncertainty is crucial. Companies often can’t answer the simplest questions. I say implement solutions that give you insights in vulnerabilities, threats, assets and ultimately risks (no, the answer isn’t an annual risk-analysis paper exercise). Then (!) implement measures for risk reduction.

The article agrees with me on Application awareness, and as I, also reference Palo Alto Networks App-ID. In addition to that, Gartner also feels that integrated IPS-functionallity will be “next-generation”, which I don’t agree with. Integrated IPS-functionallity gives no new security functionallity. It is perhaps more practical, but it doesn’t solve any problems that IPS-systems have. That the article don’t mention identity awareness is sad in an otherwise great piece.

And, sometimes I wonder what Gartner is smoking. These paragraphs got my attention

CheckPoint, Cisco, and Juniper, for instance, already have some initial basic IPS capabilities in their firewalls today, Young says. “It’s less about firewalls and more about how networks and users have changed,” he says. “As they change, the firewall is forced to change.”

Gartner, Juniper is offering their full blown IPS as a blade in their ISG-series (Integrated Security Gateway).

Just over the last year, the kinds of vulnerabilities that are being exploited are very different from the ones being exploited in the past.

Really? They are referring to vulnerabilities in client applications and web services, which are essentially just input validation flaws just as format string attacks and many buffer overflows. What is different is that the threat are targeting “very different software” but the the vulnerabilities are not “very different”.

They also doesn’t seem to understand the Date of Birth of a vulnerability:

We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications.

What they mean growth in the number of disclosed client-side vulnerabilities, because applications like Firefox, IE 6 and Acrobat Reader were all developed in 2006 and as such should be featured in those statistics if they want to express their growth. Here they suddenly get it:

Web application vulnerabilities in open-source as well as custom-built applications account for almost half the total number of vulnerabilities being discovered in the past year.

I think it’s sloppy by SANS to not take care when choosing their words. It has become something that is almost expected. Besides that, the report features some good content.

DOB = The “date of birth” of the vulnerability. For software manufacturers, this is the date of first release to users. For enterprises, this is the date of implementation of the software that has the vulnerability in question.

We shouldn’t be so focused on statistics of publicised vulnerabilities since they don’t measure the existence of vulnerabilities, but more likely the effort in finding them. The only way we can decrease the total amount of vulnerabilities are to get rid of them, i.e. by patching. Likewise, the only way we can increase the total amount of vulnerabilities is to add code with vulnerabilities, i.e. create new insecure applications (or perhaps a patch?). Since patches usually follows from vulnerability annoncements that should mean that more vulnerability disclosures means more patches which means more secure software. So, shouldn’t we be conserned if publically announced vulnerabilities drops?

“protect data at rest, in motion, and in use through deep content analysis???.

The technology used is similar to Intrusion Prevention by both it’s name and by its means (content analysis). The main difference is that they look for indications of leaking data instead of attacks. Here is a great six-part overview of these products by ex-Gartner analyst Rich Mogul.

Somehow I’m pessimsistic about these solutions. The simple reason is that it is is resonable to assume that a person with the intents of leaking data would at least take some action to do it stealthy. Some simple actions that causes problems for these solutions would be to:

• Transfer the information by other protocols than standard messaging such as HTTP, SMTP or IM. Why not use Cryptcat, DNS, ICMP or another covert channel? Or chop it up and send it by many different protocols?
• Use another physical mean of transporation. Why not save it on a floppy, cd-rom, usb-drive or beam it to the PDA? Take a photo of it or just try to remember it?
• Modify the information. Why not rename or resave the file, translate the information to another language, encode or encrypt it?

The failure to combat these is why some argue that DLP solutions are limited to preventing mistakes, rather than intentional leaks. I suppose issues with credit-card and identity theft is driving companies in investing in these solutions, and the belief that these systems will act as another layer when their intrusion prevention systems fails on them.

We tested intrusion-prevention systems in two scenarios: protecting clients (such as Web browser) and protecting servers (such as Web and e-mail servers) separately. The percentages shown are scores from our tests using Mu Security’s Mu-4000 Security Analyzer appliance to launch the attack traffic, showing what percentage of the known vulnerabilities in each category (attacks against clients, and against servers) was caught by each IPS.

The tool used in the tests are from mu Security. My, very rough, analysis of the results

• Juniper has the greatest detection and prevention rate with 87 procent catch rate of server-side attacks and 70 procent of client-side attacks. My conclusion is as such that IPS systems -at best- prevents us from roughly 80 procent of known vulnerabilities. Interestingly, this equals the ineffectiveness of anti-malware technology.
• By doing a quick overview of the results I would say that the avarage prevention rate is around 35 procent of known vulnerabilities, validating that my saying that IPS-systems in general provide very little value.

A very important thing to say about the test is that it in no way models the nature of the threat. The tests are based on publically known vulnerabilities and exploits which all of the vendors have had access to if they had care to look for them (or contact mu Security for a couple of test runs). In reality, we face issues such as evasion, noise, unkown vulnerabilities and unknown services. The results of this test are as such the best possible outcome and should be considered overly optimistic. Still interesting, and WAY better than SC Magazines attempt.

Why do trend analysis? First, trend analysis is what a statistician will recommend when the underlying topic of interest is changing and the method of measuring it is uncertain. In such a circumstance, and so long as the measurement you do have can be applied consistently, the trend data can be relied on and it is what you need for decision support. Of course, making decisions early is more expensive in decision cost than making them later, but then again later decision making generally comes with fewer workable options.

I’ll go there whenever I need figures, and to understand what they mean.

Here’s an interview that highlights these systems inability to do just that. From the interview,

In the majority of cases, they [read: IDS/IPS] just don???t end up doing what they were purchased for. An easy test that most fail is with basic port scans (that almost all are configured to pick up). We assume most are picking up ???loud??? scans (really fast and obvious scans with no attempt to be sneaky about what we are doing), but few people are pulling us up on this. (Keep in mind, with a majority of our tests, we recommend that clients don???t tell the operations team responsible for monitoring these devices that we are going to test ??? thereby, we also test the response effectiveness).

Validation and feedback is one of the pillars of security. It’s the only way that these solutions provide security assurance - they don’t do that right out of the box.

This is also spot on

An IPS only forces the attacker to know their exploits better, and take things slower. For instance, an IPS may drop all packets that have NOP sleds in them (0??909090 etc) which is used in a lot of (kind of sloppy) buffer overflows. It is however possible for an attacker to stop the IPS from seeing this.

What fails here, as well as in the earlier port-scan example, is the lack of response. Any alert or action that comes from a targeted penetration attempt should be followed by watchlisting relevant IPs and looking for further signs and attempts, possibly looking at capturing flow and full content data and other types of logs etc. Blocking shouldn’t be limited to the specific session that holds the exploit, but more importantly any following traffic. That will make the assessor work for their money.

Define where to send sFlow-records

configure sflow collector ip 6343 vr "vr-default"

Configure the sample rate. Here the switch is the configured to look at every 512:th packet. InMon provides recommended settings depending on network and traffic.

configure sflow sample-rate 512

Configure a limit as to how many samples the CPU can process at a time, this avoids the sampling process from having impact on the performance of the switch.

configure sflow max-cpu-sample.limit 2000

Enable sFlow sampling on chosen ports. Remember that sFlow is only sampled on ingress traffic - i.e. traffic coming into the specific port. This means that we have to enable sFlow on at least two ports in order to sample traffic going in both directions.

enable sflow ports 1,2

And of course

save

If I recall everything correctly that is about it. InMon has a good reference for sFlow in general and product specific configuration

The primary goal of a security monitoring and attack detection system is to help identify suspicious events on a network that may indicate malicious activity or procedural errors.

Microsoft apperently understands the importance of really looking for indications of attacks, instead of living in belief that systems are impenetrable and that security products will offer protection. Their suggestions with regards to the actual process and routine is also accurate:

A security monitoring solution is actually a continual process of planning, implementing, managing, and testing, because that is the very nature of security monitoring. Because the threats to business networks are always changing, the system that monitors the security in a business network must also change.

This process is suggested as a part of their Microsoft Operations Framework (MOF), which also features other operational routines.

I like that Microsoft is putting some effort in the defining the operational requirements for managing their systems and environments. The lack of these kind of security operations are what makes companies fail, not that they don’t have enough security products. The article also features some good hints on analysing Window Event Logs.

Leaving that aside, two things strikes me.

First, what are the critera for deciding what is best? Best as protection against security incidents, most good looking, easiest to administer or the least pricey? Have the voters something to compare with? The results would most likely point to “the most used”, not “the best in terms of protection”. When the results of the “competition” is presented and Snort is the winner, then I consider myself right :)

Secondly, how have the nominees been decided? Among the nominees I see a product that only does wireless (AirDefence), a product that only looks at the host (CA HIPS), a UTM-product (Fortinet), a NBAD-product (lancope), and finally, but also the most striking: an IPS as a managed service (Verisign). Hell, on what criteria have they decided upon these vendors/products? And where are their competitiors such as Juniper, TopLayer, and why not Bro, and where are all the SIEM-solutions?

NSS has the closest thing to a good evaluation standard of IDS/IPS-system. Not perfect though, but I hope people look, and pay, for those reports instead of making decisions on the results of crappy “competitions”.