Research points to SIEM-as-a-Service

SC Magazine released the results of a research survey focused on the rising acceptance of SIEM-as-a-Service for the small and medium sized enterprise.

The survey, conducted in April 2016, found that SMEs and companies with $1 billion or more in revenue or 5,000-plus employees faced similar challenges:

  • 64 percent of respondents agreed that they “lack the time to manage all the security activities.”
  • 49 percent reported a lack of internal staff to address IT security challenges
  • 48 percent said they lacked the IT security budget needed to meet those challenges

This come as no surprise to us. We’ve been seeing these trends rise over the past several years. Gartner reports that by 2019, total enterprise spending on security outsourcing services will be 75 percent of the spending on security software and hardware products, and that by 2020, 40 percent of all security technology acquisitions will be directly influenced by managed security service provider (MSSP) and on-premises security outsourcing providers, up from less than 15% today.

It used to be that firewalls and antivirus were sufficient enough stop gaps; but in today’s complex threatscape, the cyber criminals are more sophisticated. The weak point of any security approach is usually the unwitting victim of a phishing scam or the person who plugs in the infected USB; but “securing the human” requires the expertise of other humans, trained staff with the certification and expertise to monitor the network and analyze the anomalies. An already busy IT staff can become even more overburdened; identifying, training and keeping security expertise is hard. So is keeping up with the alerts that come in on a daily basis, and being current on the SIEM technology.

Thus, the increasing movement towards a co-managed SIEM which allows the enterprise to have access to the expertise and resources they need to run an effective security program without ceding control. SIEM-as-a-Service: saving time and money.

You can download the SC Magazine report here.

Is it all about zero-day attacks?

The popular press makes much of zero-day attacks. These are attacks based on vulnerabilities in software that is unknown to the vendor. This security hole is then exploited by hackers before the vendor becomes aware and hurries to fix it—this exploit is called a zero day attack.

However, the reality is 99.99% of exploits are based on vulnerabilities already known for at least one year. Hardly zero-day.

What does this mean to you? It means you should prioritize vulnerability scanning to first identify and then patch and manage these vulnerabilities in your defense strategy. What is the point in obsessing over zero-day vulnerabilities when unpatched systems exist within your perimeter?

What’s so hard about this? Well, for many organizations, it’s the process and expertise that is needed to accomplish the related tasks. Procuring the technology is easy but that represents, at most, 20% of the challenges to obtain a successful outcome.

The people and process to leverage the technology are 80% of the challenge. The bulk of the iceberg below the waterline, which can sink your otherwise massive ship.

Top 3 traits of a successful Security Operations Center

Traditional areas of risk — financial risk, operational risk, geopolitical risk, risk of natural disasters — have been part of organizations’ risk management for a long time. Recently, information security has bubbled to the top, and now companies are starting to put weight behind IT security and Security Operations Centers (SOC).

Easier said than done, though. Why you ask? Two reasons:

  • It’s newer, so it’s less understood; process maturity is less commonly available
  • Skill shortages — many organizations might not yet have the right skill mix and tools in-house.

From our own experience creating and staffing an SOC over the past three years, here are the top three rules:

1) Continuous communication

It’s the fundamental dictum (sort of like “location” in real estate). Bi-directional management to the IT team.

Management communicates business goals to the technology team. In turn, the IT team explains threats and their translation to risk. Management decides the threat tolerance with their eye on the bottom line.

We maintain a Runbook for every customer which records management objectives and risk tolerance.

2) Tailor your team

People with the right skills are critical to success and often the hardest to assemble, train and retain. You may be able to groom from within. Bear in mind, however, that even basic skills, such as log management, networking expertise and technical research (scouring through blogs, pastes, code, and forums), often come after years of professional information security experience.

Other skills, such as threat analysis, are distinct and practiced skill sets. Intelligence analysis, correlating sometimes seemingly disparate data to a threat, requires highly developed research and analytical skills and pattern recognition.

When building or adding to your threat intelligence team, especially concerning external hires, personalities matter. Be prepared for Tuckman’s stages of group development.

3) Update your infrastructure

Security is 24x7x365 – automatically collect, store, process and correlate external data with internal telemetry such as security logs, DNS logs, Web proxy logs, Netflow and IDS/IPS. Query capabilities across the information store requires an experienced data architect. Design fast and nimble data structures with which external tools integrate seamlessly and bi-directionally. Understand not only the technical needs of the organization, but also be involved in a continuous two-way feedback loop with the SOC, vulnerability management, incident response, project management and red teams.

Easy, huh?

Feeling overwhelmed? Get SIEM Simplified on your team. We analyze billions of logs every day. See what we’ve caught.

Is the IT Organizational Matrix an IT Security Problem?

Do you embrace the matrix?

Not this one, but the IT Organizational Matrix, or org chart. The fact is, once networks get to a certain size, IT organizations begin to specialize and small kingdoms emerge. For example, endpoint management (aka Desktop) may be handled by one team, whereas the data center is handled by another (Server team).  Vulnerability scanning may be handled by a dedicated team but identity management (Active Directory? RSA tokens?) is handled by another.  At this level of organization, these teams tend to have their own support infrastructure.

However, InfoSec controls are not separable from IT.  What this matrix at the organizational level becomes is a graph of security dependencies at the information level.  John Lambert explains in this blog post.

For example, the vulnerability scanning systems may use a “super privileged account” that has admin rights on every host in the network to scan for weaknesses, but the scanners may be patched or backed up by the Server team with admin rights to them.  And the scanner servers themselves are accessed with admin rights from a set of endpoints that are managed by the Desktop team.

This matrix arising from domain specialization creates a honeycomb of critical dependencies. Why is this a problem? Well because it enables lateral movement. Attackers who don’t know the map or org chart can only navigate the terrain as it exists. In this case, though, the defenders may manage from the network map like good little blue tin soldiers.

If this is your situation, it’s time to simplify. Successful defenders manage from the terrain, not the map.

2015 Cyber Attack Trends — 2016 Implications

Red teams attack, blue teams defend.
That’s us – defending our network.

So what attack trends were observed in 2015? And what do they portend for us blue team members in 2016?

The range of threats included trojans, worms, trojan downloaders and droppers, exploits and bots (backdoor trojans), among others. When untargeted (more common), the goal was profit via theft. When targeted, they were often driven by ideology.

Over the years, attackers have had to evolve their tactics to get malware onto computers that have improved security levels. Attackers are increasingly using social engineering to compromise computer systems because vulnerabilities in operating systems have become harder to find and exploit.

Ransomware that seeks to extort victims by encrypting their data is the new normal, replacing rogue security software or fake antivirus software of yesteryear that was used to trick people into installing malware and disclosing credit card information. Commercial exploit kits now dominate the list of top exploits we see trying to compromise unpatched computers, which means the exploits that computers are exposed to on the Internet are professionally managed and constantly optimized at an increasingly quick rate.

However, one observation made by Tim Rains, Chief Security Advisor at Microsoft was, “although attackers have accumulated more tricks and tactics and seem to be using them in a more focused, fast paced way, they still focus on a relatively small number of ways to compromise computers.” These include:

  • Unpatched vulnerabilities
  • Misconfigured computers
  • Weak passwords
  • Social engineering

In fact, Rains goes on to note: “Notice I didn’t use the word ‘advanced.’

As always, it’s back to basics for blue team members. The challenge is to defend:

  • At scale (every device on the network, no exceptions)
  • Continuously (even on weekends, holidays etc.), and
  • Update/upgrade tactics constantly

If this feels like Mission Impossible, then you may be well served by a co-managed service offering in which some of the heavy lifting can be taken on by a dedicated team.

Your SIEM relationship status: It’s complicated

On Facebook, when two parties are sort-of-kind-of together but also sort-of, well, not, their relationship status reads, “It’s complicated.” Oftentimes, Party A really wants to like Party B, but Party B keeps doing and saying dumb stuff that prevents Party A from making a commitment.

Is it like that between you and your SIEM?

Here are dumb things that a SIEM can do to prevent you from making a commitment:

  • Require a lot of work, giving little in return
  • Be high maintenance, cost a lot to keep around
  • Be complex to operate, require lots of learning
  • Require trained staff to operate

Simplify your relationship with your SIEM with a co-managed solution.

Top 5 SIEM complaints

Here’s our list of the Top 5 SIEM complaints:

1) We bought a security information and event management (SIEM) system, but it’s too complicated and time-consuming, so we’re:

a) Not using it
b) Only using it for log collection
c) Taking log feeds, but not monitoring the alerts
d) Getting so many alerts that we can’t keep up with them
e) Way behind because the person who knew about the SIEM left

2) We’re updating technology and need to retrain to support it

3) It’s hard to find, train and retain security expertise

4) We don’t have enough trained staff to manage all of our devices

5) We don’t have trained resources to successfully respond to a security incident

What’s an IT Manager to do?
Get a co-managed solution, of course.
Here’s our’s. It’s called SIEM Simplified.
Billions of logs analyzed daily. See what we’ve caught.

The Cost of False IT Security Alarms

Think about the burglar alarm systems that are common in residential neighborhoods. In the eye of the passive observer, an alarm system makes a lot of sense. They watch your home while you’re asleep or away, and call the police or fire department if anything happens. So for a small monthly fee you feel secure. Unfortunately, there are a few things that the alarm companies don’t tell you.

1)      Between 95% and 97% of calls (depending on the time of year) are false alarms.

2)      The police regard calls from alarm companies as the lowest priority and it can take anywhere between 20-30 minutes for them to arrive. It only takes the average burglar 5 minutes to break and enter, and be off with your valuables.

3)      In addition to this, if your call does turn out to be a false alarm, the police and fire department have introduced hefty fines. It is about $130 for the police to be called out, and if fire trucks are sent, they charge around $410 per truck (protocol is to send 3 trucks). So as you can see, one false alarm can cost you well over $1,200.

With more than 2 million annual burglaries in the U.S., perhaps it’s worth putting up with so many false positives in service of the greater deterrent? Yes, provided we can sort out the false alarms which sap the first responder.

The same is true of information security. If we know which alerts to respond to, we can focus our time on those important alerts. Tuning the system to reduce the alerts, and removing the false positives so we can concentrate only on valid alerts, gives us the ability to respond only to the security events that truly matter.

While our technology does an excellent job of detecting possible security events, it’s our service, which examines these alerts and provides experts who make it relevant using context and judgement, that makes the difference between a rash of false positives and the ones that truly matter.

SIEM: Sprint or Marathon?

Winning a marathon requires dedication and preparation. Over long periods of time. A sprint requires intense energy but for a short period of time. While some tasks in IT Security are closer to a sprint (e.g., configuring a firewall), many, like deploying and using a Security Information and Event Management (SIEM) solution, are closer to a marathon.

What are the hard parts?

  1. Identifying the scope
  2. Ingesting log data and filtering out noise events
  3. Reviewing the data with discipline

Surveys show that 75% of organizations need to perform significant discovery to determine which devices, platforms, applications and databases should be included in the scope for log monitoring. The point is that when most companies really evaluate their log monitoring process, most of them don’t really know what systems are even available for them to include. They don’t know what they have. Additionally, 50% of organizations later realize that this initial discovery phase is not sufficient to meet their security needs. So, even after performing the discovery, they are not sure they have identified the right systems.

While on-boarding new clients, we usually identify legacy systems or firewall policies that generate large volumes of unnecessary data. This includes discovery of service accounts or scripts with expired credentials that appear to generate suspicious looking login failures. Other common items uncovered include network health monitoring systems which generate an abnormal amount of ICMP or SNMP activity, backup tools and internal applications using non-standard ports and cleartext protocols. Each of these false positives or legitimate activities add straw to the haystack(s), which makes it more difficult to find the needle. Every network contains activities that might appear suspicious or benign to an outside observer that lacks background on everyday activities of the company being monitored. It is important for network and security administrators to provide monitoring tools with additional context and background detail to account for the variety of networks that are thrown at them.

Reviewing the data with discipline is a difficult ask for organizations with a lean IT staff. Since IT is often viewed as a “cost center,” it is rare to see organizations (esp. mid-sized ones) with suitably trained IT Security staff.

Take heart — if getting there using only internal resources is a hard problem, our SIEM Simplified service gets you there. The bonus is the cost savings compared to a DIY approach.

5 IT Security resolutions

Ho hum. Another new year, time for some more New Year’s resolutions. Did you keep the ones you made last year? Meant to but somehow did not get around to it? This time how about making it easy on yourself?

New Year Resolutions for IT security

Here are some New Year’s resolutions for IT security that you can keep easily — by doing nothing at all!

5) Give out administrator privileges freely to most users. Less hassle for you. They don’t need to bother asking you install software or access some files.

4) Don’t bother inventorying hardware or software. It changes all the time. It’s hard to maintain a list, and what’s the point anyway?

3) Allow unfettered mobile device usage in the network. You know they are going to bring their own phone and tablet anyway. It’s better this way. Maybe they’ll get more work done now.

2) Use default configurations everywhere. It’s far easier to manage. Factory default resets are needed anyway and then you can find the default password on google.

And our favorite:

1) Ignore logs of every kind — audit logs, security logs, application logs. They just fill up disk space anyway.

SIEM and Return on Security Investment (RoSI)

The traditional method for calculating standard Return on Investment (RoI) is that it equals the gain minus the cost, divided by the cost. The higher the resulting value, the greater the RoI. The difficulty in calculating a return on security investment (RoSI), however, is that security tends not to increase profits (gain), but to decrease loss – meaning that the amount of loss avoided rather than the amount of gain achieved is the important element.

Following the standard RoI approach, RoSI can be calculated by the sum of the loss reduction minus the cost of the solution, divided by the cost of the solution. In short, a high result is better for RoI, and a low result is better for RoSI.

This is where it gets difficult: how do you measure the ‘loss reduction’? To a large extent it is based on guesswork and surveys. Bruce Schneier in The Data Imperative concluded, “Depending on how you answer those two questions, and any answer is really just a guess — you can justify spending anywhere from $10 to $100,000 annually to mitigate that risk.”

What we find as a practical outcome of delivering our SIEM-as-a-service offering (SIEM Simplified) is that many customers value the anecdotes and statistics that are provided in the daily reports and monthly reviews to demonstrate RoSI to management. Things such as how many attacks were repulsed by the firewalls, how many incidents were addressed by criticality, anecdotal evidence of an attack disrupted or misconfiguration detected. We publish some of these anonymously as Catch of the Day.

It’s a practical way to demonstrate RoSI which is easier to understand and does not involve any guesses.

Stuff the turkey, not the SIEM

Did you know that SIEM and Log Management are different?

The latter (log management) is all about collecting logs first and worrying about why you need them second (if at all). The objective is “let’s collect it all and have it indexed for possible review. Why? Because we can.”

The former (SIEM) is about specific security use cases. SIEM is a use-case driven technology. Use cases are implementation specific, unlike antivirus or firewalls.
Treating SIEM like Log Management, is a lot like a turducken.

Don’t want that bloated feeling like Aunt Mildred explains here? Then don’t stuff your SIEM with logs absent a use case.

Need help doing this effectively? A co-managed SIEM may be your best bet.

Effective cyber security by empowering people

You have, no doubt, heard that cyber security is everyone’s job. So then, as the prime defender of your network, what specifically are you doing to empower people so they can all act as sentries? After all, security cannot be automated as much as you’d like. Human adversaries will always be smarter than automated tools and will leverage human ingenuity to skirt around your protections.

But, marketing departments in overdrive are busy selling the notion of “magic” boxes that can envelope you in a protective shell against Voldemort and his minions. But isn’t that really just fantasy? The reality is that you can’t replace well-trained security professionals exercising judgment with computers.

So what does an effective security buyer do?

Answer: Empower the people by giving them tools that multiply their impact and productivity, instead of trying to replace them.

When we were designing EventTracker 8, an oft repeated observation from users was the shortage of senior analysts. If they existed at all in the organization, they were busy with higher level tasks such as policy creation, architecture updates and sometimes critical incident response. The last task on their plates was the bread-and-butter of log review and threat monitoring. Such tasks are often the purview of junior analysts (if they exist). In response, many of the features of EventTracker 8 are designed specifically to enable junior administrators to make effective contributions to cyber security.

Still feeling overwhelmed by the daily tasks that need doing, consoles that need watching, alerts that need triaging? Don’t fret – that is precisely what our SIEM Simplified service (SIEMaas) is designed to provide – as much, or as little help as you need. Become empowered, be effective.

Diagnosing Account Lockout in Active Directory

Symptom

Account Lockouts in Active Directory

Additional Information

“User X” is getting locked out and Security Event ID 4740 are logged on respective servers with detailed information.

Reason

The common causes for account lockouts are:

  • End-user mistake (typing a wrong username or password)
  • Programs with cached credentials or active threads that retain old credentials
  • Service accounts passwords cached by the service control manager
  • User is logged in on multiple computers or disconnected remote terminal server sessions
  • Scheduled tasks
  • Persistent drive mappings
  • Active Directory delayed replication

Troubleshooting Steps Using EventTracker

Here we are going to look for Event ID 4740. This is the security event that is logged whenever an account gets locked.

  1. Login to EventTracker console:

2. Select search on the menu bar

3. Click on advanced search

4. On the Advanced Log Search Window fill in the following details:

  • Enter the result limit in numbers, here 0 means unlimited.
  • Select the date, time range for the logs to be searched.
  • Select all the domain controllers in the required domain.
  • Click on the inverted triangle, make the search for Event ID: 4740 as shown below.

Once done hit search at the bottom.

You can see the details below. If you want to get more information about a particular log, click on the + sign

Below shows more information about this event.

Now, let’s take a closer look at 4740 event. This can help us troubleshoot this issue.

Log Name Security
Source Microsoft-Windows-Security-Auditing
Date MM/DD/YYYY HH:MM:SS PM
Event ID 4740
Task Category User Account Management
Level Information
Keywords Audit Success
User N/A
Computer COMPANY-SVRDC1
Description A user account was locked out.
Subject:
Security ID NT AUTHORITY\SYSTEM
Account Name COMPANY-SVRDC1$
Account Domain TOONS
Logon ID 0x3E7
Account That Was Locked Out:
Security ID S-1-5-21-1135150828-2109348461-2108243693-1608
Account Name demouser
Additional Information:
Caller Computer Name DEMOSERVER1
Field My Description
DateTime This shows Date/Time of event origination in GMT format.
Source This shows the Name of an Application or System Service originating the event.
Type This shows Warning, Information, Error, Success, Failure, etc.
User This is the user/service/computer initiating event. (Name with a $ means it’s a computer/system initiated event.
Computer This shows the name of server workstation where event was logged.
EventID Numerical ID of event.
Description This contains the entire unparsed event message.
Log Name The name of the event log (e.g. Application, Security, System, etc.)
Task Category A name for a subclass of events within the same Event Source.
Level Warning, Information, Error, etc.
Keywords Audit Success, Audit Failure, Classic, Connection etc.
Category This shows the name for an aggregative event class, corresponding to the similar ones present in Windows 2003 version.
Subject: Account Name Name of the account that initiated the action.
Subject: Account Domain Name of the domain that account initiating the action belongs to.
Subject: Logon ID A number that uniquely identifying the logon session of the user initiating action. This number can be used to correlate all user actions within one logon session.
Subject: Security ID SID of the locked out user
Account Name Account That Was Locked Out
Caller Computer Name This is the computer where the logon attempts occurred

Resolution

Logon into the computer mentioned on “Caller Computer Name”  (DEMOSERVER1) and look for one of the aforementioned reasons that produces the problem.

To understand further on how to resolve issues present on “Caller Computer Name”  (DEMOSERVER1) let us look into the different logon types.

LogonType Code 0
LogonType Value System
LogonType Meaning Used only by the System account.
Resolution No evidence so far seen that can contribute towards account lock out
LogonType Code 2
LogonType Value Interactive
LogonType Meaning A user logged on to this computer.
Resolution User has typed wrong password on the console
LogonType Code 3
LogonType Value Network
LogonType Meaning A user or computer logged on to this computer from the network.
Resolution User has typed wrong password from the network. It can be a connection from Mobile Phone/ Network Shares etc.
LogonType Code 4
LogonType Value Batch
LogonType Meaning Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.
Resolution Batch file has an expired or wrong password
LogonType Code 5
LogonType Value Service
LogonType Meaning A service was started by the Service Control Manager.
Resolution Service is configured with a wrong password
LogonType Code 6
LogonType Value Proxy
LogonType Meaning Indicates a proxy-type logon.
Resolution No evidence so far seen that can contribute towards account lock out
LogonType Code 7
LogonType Value Unlock
LogonType Meaning This workstation was unlocked.
Resolution User has typed a wrong password on a password protected screen saver
LogonType Code 8
LogonType Value NetworkCleartext
LogonType Meaning A user logged on to this computer from the network. The user’s password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext).
Resolution No evidence so far seen that can contribute towards account lock out
LogonType Code 9
LogonType Value NewCredentials
LogonType Meaning A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.
Resolution User initiated an application using the RunAs command, but with wrong password.
LogonType Code 10
LogonType Value RemoteInteractive
LogonType Meaning A user logged on to this computer remotely using Terminal Services or Remote Desktop.
Resolution User has typed wrong password while logging in to this computer remotely using Terminal Services or Remote Desktop
LogonType Code 11
LogonType Value CachedInteractive
LogonType Meaning A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.
Resolution No evidence so far seen that can contribute towards account lock out as domain controller is never contacted in this case.
LogonType Code 12
LogonType Value CachedRemoteInteractive
LogonType Meaning Same as RemoteInteractive. This is used for internal auditing.
Resolution No evidence so far seen that can contribute towards account lock out as domain controller is never contacted in this case.
LogonType Code 13
LogonType Value CachedUnlock
LogonType Meaning This workstation was unlocked with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.
Resolution No evidence so far seen that can contribute towards account lock out as domain controller is never contacted in this case.

How to identify the logon type for this locked out account?

Just like how it is shown earlier for Event ID 4740, do a log search for Event ID 4625 using EventTracker, and check the details.

Log Name Security
Source Microsoft-Windows-Security-Auditing
Date date
Event ID 4625
Task Category Logon
Level Information
Keywords Audit Failure
User N/A
Computer COMPANY-SVRDC1
Description An account failed to log on.
Subject:
Security ID SYSTEM
Account Name COMPANY-SVRDC1$
Account Domain TOONS
Logon ID ID
Logon Type 7
Account For Which Logon Failed:
Security ID NULL SID

Account Name demouser
Account Domain TOONS

Failure Information:
Failure Reason An Error occurred during Logon.
Status 0xc000006d
Sub Status 0xc0000380
Process Information:
Caller Process ID 0x384
Caller Process Name C:\Windows\System32\winlogon.exe
Network Information:
Workstation Name computer name
Source Network Address IP address
Source Port 0
Detailed Authentication Information:
Logon Process User32
Authentication Package Negotiate
Transited Services
Package Name (NTLM only)
Key Length 0

Logon Type 7 says User has typed a wrong password on a password protected screen saver.

Now we understand what reason to target and how to target the same.

Applies to

Microsoft Windows Servers
Microsoft Windows Desktops

Contributors

Ashwin Venugopal, Subject Matter Expert at EventTracker
Satheesh Balaji, Security Analyst at EventTracker

Index now, understand later

Late binding is a computer programming mechanism in which the method being called upon an object or the function being called with arguments is looked up by name at runtime. This contrasts with early binding, where everything must be known in advance. This method is favored in object-oriented languages and is efficient but incredibly restrictive. After all, how can everything be known in advance?

In EventTracker, late binding allows us to continue learning and leveraging new understanding instead of getting stuck in whatever was sensible at the time of indexing. The upside is that it is very easy to ingest data into EventTracker without knowing much (or anything) about its meaning or organization. Use any one of several common formats/protocols, and voila, data is indexed and available for searching/reporting.

As understanding improves, users can create a “Knowledge Pack” to describe the indexed data in reports, search output, dashboards, co-relation rules, behavior rules, etc. There is no single, forced “normalized” schema and thus no connectors to transform incoming data to the fixed schema.

As your understanding improves, the knowledge pack improves and so does the resulting output. And oh by the way, since the same data can be viewed by two different roles in very different ways, this is easily accommodated in the Knowledge Pack. Thus the same data (e.g., Login failures) can be viewed in one way by the Security team (in real time, as an alert, with trends) and in an entirely different way by the Compliance team (as a report covering a time-span with annotation to show due care).

Hallmarks of a successful security monitoring team

Over the years, we have seen many approaches to implementing a security monitoring capability.

The “checkbox mentality” is common—when the team uses the out-of-the-box functionality, including perhaps rules/reports, to meet a specific regulation.

The “big hero” approach is found in chaotic environments where tools are implemented with no planning or oversight, in a very “just do it” approach. The results may be fine, but are lost when the “big hero” moves on or loses interest.

The “strict process” organizations that implement a waterfall model and have rigid processes for change management and the like frequently lack the agility and dynamics required by today’s constantly evolving threats.

So what then are the hallmarks of a successful approach? Augusto Barrios described these factors here. Three factors are common:

  • Good people: Team members who know the environment and can create good use cases. Members who know the selected technology and can weave the rules, configuration and customize to suit.
  • Lightweight, but clear processes: Recognize that it’s very hard to move from good ideas to real (and deployed) use cases without processes. Absent this, things go to a slow death.
  • Top down and lateral support: The security team may have good people and processes to put together the use cases, but they are not an island. They will need continuous support to bring in new log sources, context data and the knowledge about the business and the environment required for implementation and optimization. They will need other people’s (IT ops, business applications specialists) time and commitment, and that’s only possible with top down support and empowerment.

Since it’s quite hard to get all of it right, an increasingly popular approach is to split the problem between the SIEM vendor and the buyer. Each has strengths critical to success. The SIEM vendor is expert with the technology, likely has well defined processes for implementation and operational success, whereas the buyer knows the environment intimately. Together, good use cases can be crafted. Escalation from the SIEM vendor who performs the monitoring is passed to the buyer team to provide lateral support. This approach has the potential to ramp up very quickly, since each team plays to their existing strengths.

The Gartner term for this approach is “co-managed SIEM.”

Want to get started quickly? Here is a link for you.

Where to focus efforts: Endpoint or Network?

The release of EventTracker 8 with new endpoint threat detection capabilities has led to many to ask: a) how to obtain these new features and b) where the focus on monitoring efforts should be, on the endpoint or on traditional attack vectors.

The answer to “a” is fairly simple and involves upgrading to the latest version; if you have licensed the suitable modules, the new features are immediately available to you.

The answer to “b” is not so simple and depends on your particular situation. After all, endpoint threat detection is not a replacement of signature based network packet sniffers. If your network permits BYOD or allows business partners to connect entire networks to yours, or permits remote access, why then network-based intrusion detection would be a must (how can you insist on sensors on BYOD?).

On the other hand, malware can be everywhere and anti-virus effectiveness is known to be weak. Phishing and drive-by exploits are real things. Perhaps even accurate inventory of endpoints (think traveling laptops) is hard. This all leads to endpoint-focused efforts as being paramount.

So really, it’s not endpoint or network-focused monitoring; rather it’s endpoint and network-focused monitoring efforts.

Feeling overwhelmed at having to deploy/manage so much complexity? Help is at hand. Our co-managed solution called SIEM Simplified is designed to take the sting out of the cost and complexity of mounting an effective defense.

The fallacy of “protect critical systems”

Risk management 101 says you can’t possibly apply the same safeguards to all systems in the network. Therefore, you must classify your assets and apply greater protection to the “critical” systems—the ones where you have more to lose in the event of a breach. And so, desktops are considered less critical as compared to servers, where the crown jewels are housed.

But think about this: an attacker will most likely probe for the weakly defended spot, and thus many widespread breaches originate at the desktop. In fact, in many cases, attackers discover crown jewels are sometimes also available at some workstations of key employees (e.g., the CEO’s assistant?), in which case there is not even a need to attack a hardened server.

So while it still makes sense to mount better defenses of critical systems, it’s equally sensible to be able to investigate compromised systems, regardless of their criticality. To do so, you must be gathering telemetry from all systems. While you may not be able to do this if you are allowing a BYOD policy, you should definitely think about data gathering from beyond just “critical systems.”

The ETDR functionality built in to the EventTracker 8 sensor (formerly agent) for Windows lets you collect this telemetry easily and efficiently. The argument here being it’s very worthwhile given the current threat landscape, to cover not just critical systems, but also desktops, with this technology.

What’s new in EventTracker 8? Find out here.

Security Subsistence Syndrome

Security Subsistence Syndrome (SSS) is defined as a mindset in an organization that believes it has no security choices and is underfunded, so it minimally spends to meet perceived statutory and regulatory requirements.

Andy Ellis describes this mindset as one “with attitude, not money. It’s possible to have a lot of money and still be in a bad place, just as it’s possible to operate a good security program on a shoestring budget.”

In the face of overwhelming evidence that traditional defenses such as signature based anti-virus and firewalls are woefully inadequate against modern threats, SSS leads defenders to proclaim satisfaction because they have been diligent in implementing these basic precautions.

However, people who deal with incident response today quietly assume that the malware will not be detected by whatever anti-virus tools are installed. The question of “does AV detect it?” never even comes up anymore. In their world, anti-virus effectiveness is basically 0% and this is not a subject of any debate. This is simply a fact of their daily life, as noted here.

So how does the modern IT manager defend effectively (and efficiently — since cost is always a concern) against this threat landscape?

The answer is in a suite of technologies now called endpoint threat detection and response (ETDR or EDR). These are IT analytics solutions which provide visibility and insight into abnormal behavior that could represent potential threats and risks and enable enterprises to improve their security posture. A sensor at the endpoint is used to detect the launch of new processes and compares the MD5 (or SHA) hash of this process to determine if it has been seen before/trusted.

Can your SIEM provide ETDR? EventTracker can. Time to upgrade?

Can you defeat a casual attacker?

The news is rife with stories on “advanced” and “persistent” attacks, in the same way as exotic health problems like Ebola. The reality is that you are much more likely to come down with the common cold than Ebola. Thus, it makes more sense to pay close attention to what the Center for Disease Control has to say about it than to stockpile Ebola serum.

In similar vein, how good is your organization in fighting basic, commodity attacks?

It is true that the scary monsters called 0-day, advanced/persistent attacks and state sponsored superhackers are real. But before worrying about these, how are you set up for traditional intrusion attempts that use (5+) year old tools, tactics and exploits? After all, the vast majority of successful attacks are low tech and old school.

Want to rapidly improve your security maturity? Consider SIEM Simplified, our surprisingly affordable service that can protect you from 90% of the attacks for 10% of the do-it-yourself cost.

When is an alert not an alert?

The Riddler is one of Batman’s enduring enemies who takes delight in incorporating riddles and puzzles into his criminal plots—often leaving them as clues for the authorities and Batman to solve.

Question: When is a door, not a door?
Answer: When it’s ajar.

So riddle me this, Batman: When is an alert not an alert?

EventTracker users know that one of its primary functions is to apply built-in knowledge to reduce the flood of all security/log data to a much smaller stream of alerts. However, in most cases, without applying local context, this is still too noisy, so a risk score is computed which factors in the asset value and CVSS score of the source.

This allows us to separate “alerts” into different priority levels. The broad categories are:

  • Actionable Alerts: these require that you pay immediate attention because it’s likely to affect the network or critical data. An analogy is that you have had a successful break-in and the intruder is inside the premises.
  • Awareness Alerts: there may not be anything to do, but administrators should become aware and perhaps plan to shore up defenses. The analogy is that bad guys have been lurking on your street and making observations about when you enter/exit the premises and when its unoccupied.
  • Compliance Alerts: these may affect your compliance posture and so bear either awareness or action on your part.

And so, there are alerts and there are alerts. Over-reacting to awareness or compliance alerts will drain your energy and eventually sap your enthusiasm, not to mention cost you in real terms. Under-reacting to actionable alerts will also hurt you by inaction.

Can your SIEM differentiate between actionable and awareness alerts?
EventTracker can.
Find out more here.

Can you predict attacks?

The “kill chain” is a military concept related to the structure of an attack. In the InfoSec area, this concept is a way of modeling intrusions on a computer network.

Threats occur in up to seven stages. Not all threats need to use every stage, and the actions available at each stage can vary, giving an almost unlimited diversity to attack sets.

  • Reconnaisance
  • Weaponization
  • Delivery
  • Exploitation
  • Installation
  • Command and Control
  • Actions on Objective

Of course, some of the steps can happen outside the defended network, and in those cases, it may not be possible or practical to identify or counter. However, the most common variety of attack is unstructured in nature and originates from external sources. These use scripts or commonly available cracking tools that are widely available. Such attacks are identified by many techniques including:

Evidence of such activities is a pre-cursor to an attack. If defenders observe the activities from external sources, then it is important to review what the targets are. Often times, these can be uncovered by a penetration test. Repeated attempts against specific targets are a clue.

A defense-in-depth strategy gives defenders multiple clues about such activities. These include IDS systems that detect attack signatures, logs showing the activities and vulnerability scans that identify weaknesses.

To be sure, defending requires carefully orchestrated expertise. Feeling overwhelmed? Take a look at our SIEM Simplified offering where we can do the heavy lifting.

The Attack on your infrastructure: a play in three parts

To defend against an attacker, you must know him and his methods. The typical attack launched on an IT infrastructure can be thought of in three stages.

Part 1: Establish a beachhead

The villain lures the unsuspecting victim to install malware. This can be done in a myriad of ways: by sending an attachment from an apparently trustworthy source, causing a drive by infection through a website hosting malware, or via a USB drive. Attackers target the weakest link, the less guarded desktop or a test system. Frontal assaults against heavily fortified and carefully watched servers are not practical.

Once installed, the malware usually copies itself to multiple spots to deter eradication and it can possibly “phone home” for further instructions. Malware usually lurks in the background, trying to obtain passwords or system lists to further enable Part 2.

Part 2: Move laterally

As a means to deter removal, malware will move laterally, copying itself to other machines/locations. This movement is also often from peripheral to more central systems (e.g., from workstations to file shares).

Part 3: Exfiltrate secrets

Having patiently gathered up (usually zip or rar) secrets (intellectual property, passwords, credit card info, PII, etc.), the malware (or attacker)now sends the data outside the network back to the attacker.
How do you defend yourself against this? A SIEM solution can help, or a managed SIEM solution if you are short on expertise.

Outsourcing versus As-a-Service

The (toxic) term “outsourcing” has long been vilified as the substitution of onshore jobs with cheaper offshore people. As noted here, outsourcing, by and large, has really always been about people. The story of outsourcing to-date is of service providers battling it out to deliver people-based services more productively, promising delights of delivery beyond merely doing the existing stuff significantly cheaper and a bit better.

When it comes to SIEM-as-a-service though, the game-changer is centered on today’s services work as a genuine blending of people-plus-technology. This empowers service buyers to focus on value-addition through meaningful and secure data, enabled by a sophisticated tool. All good, but recognize this is fundamentally made possible by smart people working together, your team and ours.

Business services, today, are one of speed to business impact. They are about simplification. They are about removing any blockage or obstacle diluting this business impact.

We refer to our SIEM Simplified service offering as co-managed. Inherent in the term is the acknowledgement that our team must work with your to deliver value. The “simplified” part is all about the removal of unneeded complexity.

That transition to As-a-Service is all about simplification — removing unnecessary complexity, poor processes and manual intervention to make way for a more nimble way of running a business. It is also about prioritizing where to focus investments to achieve maximum benefit and impact for the business from its operations.

Do you need a Log Whisperer?

Quick, take a look at these four log entries

  1. Mar 29 2014 09:54:18: %PIX-6-302005: Built UDP connection for faddr 198.207.223.240/53337 gaddr10.0.0.187/53 laddr 192.168.0.2/53
  2. Mar 12 12:00:08 server2 rcd[308]: id=304 COMPLETE ‘Downloading https://server2/data/red-carpet.rdf’time=0s (failed)
  3. 200.96.104.241 – – [12/Sep/2006:09:44:28 -0300] “GET /modules.php?name=Downloads&d_op=modifydownloadrequest&%20lid=-%20UNION%20SELECT%200,username,user_id,
    user_password,name,%20user_email,user_level,0,0%20FROM%20nuke_users HTTP/1.1” 200 9918 “-”
    “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)”
  4. Object Open:Object Server: Security
    Object Type: File
    Object Name: E:\SALES RESOURCE\2010\Invoice 2010 7-30-2010.xls
    Handle ID: –
    Operation ID: {0,132259258}
    Process ID: 4
    Image File Name:
    Primary User Name: ACCOUNTING$
    Primary Domain: PMILAB
    Primary Logon ID: (0x0,0x3E7)
    Client User Name: Aaron
    Client Domain: CONTOSO
    Client Logon ID: 0x0,0x7E0808E)
    Accesses: DELETE
    READ_CONTROL
    ACCESS_SYS_SEC
    ReadData (or ListDirectory)
    ReadEA
    ReadAttributes
    Privileges: –
    Restricted Sid Count: 0
    Access Mask: 0x1030089

Any idea what they mean?

No? Maybe you need a Log Whisperer — someone who understands these things.

Why, you ask?
Think security — aren’t these important?

Actually #3 and #4 are a big deal and you should be jumping on them, whereas #1 and #2 are routine — nothing to get excited about.

Here is what they mean:

  1. A Cisco firewall allowed a packet through (not a “connection” because it’s a UDP packet — never mind what the text says)
  2. An attempt to update by an OpenSuSE Linux machine, but some software packages are failing to be updated.
  3. A SQL injection attempt on PHP Nuke
  4. Access denied to a shared resource in a Windows environment

Log Whisperers are the heart of our SIEM Simplified. They are the experts who review logs, determine what they mean and provide remediation recommendations in simple, easy to understand language.

Not to be confused with these guys.

And no, they don’t look like Robert Redford either. You are thinking about the Horse Whisperer.

Three Indicators of Attack

For many years now, the security industry has become somewhat reliant on ‘indicators of compromise’ (IoC) to act as clues that an organization has been breached. Every year, companies invest heavily in digital forensic tools to identify the perpetrators and which parts of the network were compromised in the aftermath of an attack.

All too often, businesses are realizing that they are the victims of a cyber attack once it’s too late. It’s only after an attack that a company finds out what made them vulnerable and what they must do to make sure it doesn’t happen again.
This reactive stance was never useful to begin with and given the threat landscape, is totally undone as described by Ben Rossi.

Given the importance of identifying these critical indicators of attack (IoAs), here are eight common attack activities that IT departments should be tracking in order to gain the upper hand in today’s threat landscape.

Here are three IoAs that are both meaningful and relatively easy to detect:

  1. After hours: Malware detection after office hours; unusual activity including access to workstations or worse yet, servers and applications, should raise a red flag.
  2. Destination Unknown: Malware tends to “phone home” for instructions or to exfiltrate data. Connections from non-browsers and/or on non-standard ports and/or to poor reputation of “foreign” destinations is a low noise indicator of breaches.
  3. Inside Out: More than 75% of attacks, per the the Mandian m-report, are done using stolen credentials. It is often acknowledged that Insider attacks are much less common but much more damaging. When an outsider becomes a (privileged) insider, your worst nightmare has come true.

Can you detect out-of-ordinary or new behavior? To quote the SANS Institute…Know Abnormal to fight Evil. Read more here.

It’s all about detection, not protection

What did the 2015 Verizon DBIR show us?
• 200+ days on average before persistent attackers are discovered within the enterprise network
• 60%+ breaches are reported by a third party
• 100% of breached networks were up to date on Anti Virus

We’ve got detection deficit disorder.
And it’s costing us. Direly!

Think of the time and money spent in detecting, with some degree of confidence, the location of Osama Bin Laden. Then think of the time and money to dispatch Seal Team 6 on the mission. Detection took ten years and cost hundreds of millions of dollars while remediation took 10 days and a few million dollars.

The same situation is happening in your network. You have for example 5,000 endpoints and of those, maybe 5 are compromised as you’re reading this. But which endpoints are compromised? How do you get actionable intelligence so that you can dispatch your own Seal Team 6?

This is the problem, EventTracker 8 was designed to address. Continuous digital forensics data collection using purpose built sensors. The machine learning at the EventTracker Console, sifts through collected data to identify possible malware, lateral movement and exfiltration of data. The processes are all backed by experts of the SIEM Simplified service.

The Detection Deficit

The gap between the ‘time to compromise’ and the ‘time to discover’ is the detection deficit. According to Verizon DBIR, the trend lines of these have been diverging significantly in the past few years. Worse yet, the data shows that attackers are able to compromise the victim in days but thereafter are able to spend an average of 243 days undetected within the enterprise network before they are exposed. More often than not, this is happening by a third party. This trend points to an ongoing detection deficit disorder. The suggestion is that defenders struggle to uncover the indicators of compromise. While the majority of these attacks are via malware inserted to the victim’s system by a variety of methods, there is also theft of credentials that make it look like an inside job. To overcome the detection deficit, defenders must look for other common evidence of compromise. These include: command and control activity, suspicious network traffic, file access and unauthorized use of valid credentials. EventTracker 8 includes features incorporated into our Windows sensor that provide continuous forensics to look for evidence of compromise.” target=”_blank”>Verizon VBIR, the trend lines of these have been diverging significantly in the past few years.

Worse yet, the data shows that attackers are able to compromise the victim in days but thereafter are able to spend an average of 243 days undetected within the enterprise network before they are exposed. More often than not, this is happening by a third party.

This trend points to an ongoing detection deficit disorder. The suggestion is that defenders struggle to uncover the indicators of compromise.

While the majority of these attacks are via malware inserted to the victim’s system by a variety of methods, there is also theft of credentials that make it look like an inside job.

To overcome the detection deficit, defenders must look for other common evidence of compromise. These include: command and control activity, suspicious network traffic, file access and unauthorized use of valid credentials.

EventTracker 8 includes features incorporated into our Windows sensor that provide continuous forensics to look for evidence of compromise.

The Agent Advantage

For some time, “We use an agent for that” was a death spell for many security tools  while “agent-less” was the only game in town worth playing. Yes, people tolerate AV and device management agents, but that is where many organizations seemed to draw the line.  And an agent just to collect logs? – You’ve got to be kidding!

In this blog from 2006, Richard Bejtlich pointed out, enterprise security teams should seek to minimize their exposure to endpoint agent vulnerabilities.

Lets not confuse the means with the end. The end is “security information/event monitoring,” while getting the logs is the means to the end. Whereas, the threatscape of 2015 is dominated by polymorphic, persistent malware (dropped by phishing and stolen credentials); where our current mission still remains to defend the network.

Malware doesn’t write logs but it does however leave behind trace evidence on the host. This is evidence that you can’t get by monitoring the network. In any case, the rise of https by default has limited the ability of the network monitor to peer inside the payload.

Thus the Agent Advantage or the Sensor Advantage if you prefer.

Endpoints have first hand information when it comes to non-signature based attacks. This includes processes, file accesses, configuration changes, network traffic, etc. This data is critical to early detection of malicious activity.

Is an “agent” just to collect logs not doing it for you? How about a “sensor” that gathers endpoint data critical to detect persistent cyber attacks? That is the EventTracker 8 sensor which incorporates DFIR and UBA.

Why host data is essential for DFIR

Attacks on our IT network are a daily fact of life. As a defender, its job is to make the attackers life harder and to deter them to go elsewhere. Any attack, almost inevitably causes some type of host artifact to be left behind.

If defenders are able to quickly uncover the presence of host artifacts, it may be possible to disrupt the attack, thereby causing pain to the attacker. Such artifacts are present on the target/host and usually not visible to network monitors.

Many modern attacks use malware that is dropped and executed on the target machine or hollows out existing valid processes to spawn child processes that can be hijacked.

A common tactic when introducing malware on a target is to blend in. If the legitimate process is called svchost.exe, then the malware may be called svhost.exe. Another tactic is to maintain the same name as the legitimate EXE but have it executed from a different path.

EventTracker 8 includes a new module called Advanced Security Analytics which provides tools to help automate the detection of such attacks. When any process is launched, EventTracker gathers various bits of information about the EXE including, its hash, its full path name, its parent process, the publisher name and if it’s digitally signed or not. Then at the EventTracker Console, if the hash is being seen for the first time, it gets compared to lists of known malware from sources such as virustotal.com, virusshare.com etc. Analysts can also look and see if the EXE was digitally signed by the publisher name and source to determine if further investigation is warranted.

When tuned properly, this capability results in low false positive and can be useful to rapidly detect attackers.

Want more information on EventTracker 8? Click here.