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.

Cloud Security Starts at Home

Cloud security is getting attention and that’s as it should be.  But before you get hung up on techie security details, like whether SAML is more secure than OpenID Connect and the like, it’s good to take a step back.  One of the tenets of information security is to follow the risk.  Risk is largely a measure of damage and likelihood.  When you are looking at different threats to the same cloud-based data then it becomes a function of the likelihood of those risks.

In the cloud we worry about the technology and the host of the cloud.  Let’s focus on industrial-strength infrastructure and platform-as-a-service clouds like AWS and Azure.  And let’s throw in O365 – it’s not infrastructure or platform, but its scale and quality of hosting fits our purposes in terms of security and risk.  I don’t have any special affection for any of the cloud providers, but it’s a fact that they have the scale to do a better, more comprehensive, more active job on security than my little company does, and I’m far from alone.  This level of cloud doesn’t historically get hacked because of stupid operational mistakes or flimsy coding practices with cryptography and password handling, or because of obscure vulnerabilities in standards like SAML and OpenID Connect (they are present). It’s because of tenant-vectored risks.  Either poor security practices by the tenant’s admins or vulnerabilities in the tenant’s technology which the cloud is exposed to or on which it is reliant.

Here are just a few scenarios of cloud intrusions with a tenant origin vector Tenant Vulnerability Cloud Intrusion
1. Admin’s PC infected with malware Cloud tenant admin password stolen
2. Tenant’s on-prem network penetrated VPN connection between cloud and on-prem network
3. Tenant’s Active Directory unmonitored Federation/synchronization with on-prem AD results in an on-prem admin’s account having privileged access to the cloud.

I’m going to focus on the latter scenario.  The point is that most organizations integrate their cloud with their on-prem Active Directory, and that’s as it should be.  We hardly want to go back to the inefficient and insecure world of countless user accounts and passwords per person.  We were able to largely reduce that of the years by bringing more and more on-prem apps, databases and systems online with Active Directory.  Let’s not lose ground on that with the cloud.

But your greatest risk in the cloud might just be right under your nose here in AD on your local network.  Do you monitor changes in Active Directory?  Are you aware when there are failed logons or unusual logons to privileged accounts?  And I’m not just talking about admin accounts.  Really, just as important, are those user accounts who have access to the data that your security measures are all about.  So that means identifying not just the IT groups in AD, but also those groups which are used to entitle users to that important data.  Very likely some of those groups are re-used in the cloud to entitle users there as well.  Of course the same goes for the actual user accounts.

Even for those of us who can say our network isn’t connected by VPN or any direct connections (like ExpressRoute for Azure/O365) and there’s no federation or sync between our on-prem and cloud directories your on-prem, internal security efforts will make or break your security in the cloud and that’s simply because of #1.  At some point your cloud admin has to connect to the cloud from some device.  And if that device isn’t secure or the cloud admin’s credential handling is lax, you’re in trouble.

That’s why I say that for most of us in the cloud need to first look inward for risks.  Monitoring, as always, is key.  The detective control you get with a well implemented and correctly used SIEM is incredible and often the only control you can deploy at key points, technologies or processes in your network.

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.

Certificates and Digitally Signed Applications: A Double Edged Sword

Windows supports the digitally signing of EXEs and other application files so that you can verify the provenance of software before it executes on your system.  This is an important element in the defense against malware.  When a software publisher like Adobe signs their application they use the private key associated with a certificate they’ve obtained from one of the major certification authorities like Verisign.

Later, when you attempt to run a program, Windows can check the file’s signature and verify that it was signed by Adobe and that its bits haven’t been tampered with such as by the insertion of malicious code.

Windows doesn’t enforce digital signatures or limit which publisher’s programs can execute by default, but you can enable that with AppLocker.  As powerful as AppLocker potentially is, it is also complicated to set up, except for environments with a very limited and standardized set of applications.  You must create rules for at least every publisher whose code runs on your system.

The good news, however, is that AppLocker can also be activated in audit mode.  And you can quickly set up a base set of allow rules by having AppLocker scan a sample system.  The idea with running AppLocker in audit mode is that you then monitor the AppLocker event log for warnings about programs that failed to match any of the allow rules.  This means the program has an invalid signature, was signed by a publisher you don’t trust or isn’t signed at all.  The events you look for are 8003, 8006, 8021 and 8024 and these events are in the logs under AppLocker as shown here:

AppLocker_Events to Look For

These events are described here, which is part of the AppLocker Technical Reference.

If you are going to use AppLocker in audit mode for detecting untrusted software remember that Windows logs these events on each local system.  So be sure you are using a SIEM with an efficient agent, like EventTracker, to collect these events or use Windows Event Forwarding.

Better yet, if you have EventTracker, don’t bother with AppLocker – use EventTracker’s automatic Digital Forensics Incident and Incident Response feature for unknown processes.  EventTracker watches each process (and soon each DLL) that your endpoints load and checks the EXE’s hash against your environment’s local whitelist (which EventTracker can automatically build). If not found there, EventTracker checks it against the National Software Reference Library.  If the EXE still isn’t found to be legit, EventTracker posts it to the dashboard for you to review.  EventTracker automatically provides publisher information if the file is signed, and other forensics such as the endpoint, user and parent process.  With one click you can check the process against anti-malware sites such as VirusTotal. EventTracker goes way beyond AppLocker in its ability to detect suspicious software and giving the tools and information to quickly determine if the program is a risk or not, including the use of digital signatures.

There are some other issues to be aware of, though, with digitally signed applications and certificates.  Certificates are part of a very complicated technology called Public Key Infrastructure (PKI).  PKI has so many components and ties together so many different parties there is unfortunately a lot of room for error.   Here’s a brief list of what has gone wrong in the past year or so with signed applications and the PKI that signatures depend on:

  1. Compromised code-signing server: I’d said earlier that code signing allows you to make sure a program really came from the publisher and that it hasn’t been modified (tampered).  But it depends on how well the publisher protects their private key.  And unfortunately Adobe is a case in point.  A while back some bad guys broke into Adobe’s network and eventually found their way to the very server Adobe uses to sign applications like Acrobat.  They uploaded their own malware and signed it with Adobe’s code signing certificate’s private key and then proceeded to deploy that malware to target systems that graciously ran the program as a trusted Adobe application.  How do you protect against publishers that get hacked?  There’s only so much you can do.  You can create stricter rules that limit execution to specific versions of known applications but of course that makes your policy much more fragile.
  1. Fraudulently obtained certificates: Everything in PKI depends on the Certification Authority only issuing certificates after rigorously verifying the party purchasing the certificate is really who they say they are.  This doesn’t always work.  A pretty recent example is Spymel a piece of malware signed by a certificate DigiCert issued to a company called SBO Invest.  What can you do here?  Well, using something like AppLocker to limit software to known publishers does help in this case.  Of course if the CA itself is hacked then you can’t trust any certificate issued by it.  And that brings us to the next point.
  1. Untrustworthy CAs: I’ve always been amazed at all the CA Windows trusts out of the box.  It’s better than it used to be but at one time I remember that my Windows 2000 system automatically trusted certificates issued by some government agency of Peru.  But you don’t have trust every CA Microsoft does.  Trusted CAs are defined in the Trusted Root CAs store in the Certificates MMC snap-in and you can control the contents of this store centrally via group policy
  1. Insecure CAs from PC Vendors: Late last year Dell made the headlines when it was discovered that they were shipping PCs with their own CA’s certificate in the Trusted Root store.  This was so that drivers and other files signed by Dell would be trusted.   That might have been OK, but they mistakenly broke The Number One Rule in PKI.  They failed to keep the private key private.  That’s bad with any certificate let alone a CA’s root certificate.  Specifically, Dell included the private key with the certificate.  That allowed anyone that bought an affected Dell PC to sign their own custom malware with Dell’s private key and then once deployed on other affected Dell systems to run it with impunity since it appeared to be legit and from Dell.

So, certificates and code signing are far from perfect — show me any security control that is.  I really encourage you to try out AppLocker in audit mode and monitor the warnings it produces.  You won’t break any user experience, the performance impact is hardly measurable and if you are monitoring those warnings you might just detect some malware the first time it executes instead of the 6 months or so that it takes on average.

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.

The Assume Breach Paradigm

Given today’s threat landscape, let’s acknowledge that a breach has either already occurred within our network or that it’s only a matter of time until it will. Security prevention strategies and technologies cannot guarantee safety from every attack. It is more likely that an organization has already been compromised, but just hasn’t discovered it yet.

Operating with this assumption reshapes detection and response strategies in a way that pushes the limits of any organization’s infrastructure, people, processes and technologies.

In the current threat landscape, a prevention-only focus is not enough to address determined and persistent adversaries. Additionally, with common security tools, such as antivirus and Intrusion Detection Systems (IDS), it is difficult to capture or mitigate the full breadth of today’s breaches. Network edge controls may keep amateurs out, but talented and motivated attackers will always find the means to get inside these virtual perimeters. As a result, organizations are all too often ill prepared when faced with the need to respond to the depth and breadth of a breach.

Assume Breach is a mindset that guides security investments, design decisions and operational security practices. Assume Breach limits the trust placed in applications, services, identities and networks by treating them all—both internal and external—as not secure and probably already compromised.

While Prevent Breach security processes, such as threat modeling, code reviews and security testing may be common in secure development lifecycles, Assume Breach provides numerous advantages that help account for overall security by exercising and measuring reactive capabilities in the event of a breach.

assume breach

With Assume Breach, security focus changes to identifying and addressing gaps in:

  • Detection of attack and penetration
  • Response to attack and penetration
  • Recovery from data leakage, tampering or compromise
  • Prevention of future attacks and penetration

Assume Breach verifies that protection, detection and response mechanisms are implemented properly — even reducing potential threats from “knowledgeable attackers” (using legitimate assets, such as compromised accounts and machines).

To defend effectively, we must:

  • Gather evidence left by the adversary
  • Detect the evidence as an Indication of Compromise
  • Alert the appropriate Engineering and Operation team(s)
  • Triage the alerts to determine whether they warrant further investigation
  • Gather context from the environment to scope the breach
  • Form a remediation plan to contain or evict the adversary
  • Execute the remediation plan and recover from breach

Since this can be overwhelming for any but the largest organizations, our SIEM Simplified service is used by many organizations to supplement their existing teams. We contribute our technology, people and processes to the blue team and help defend the network.

See what we’ve caught recently.

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


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.


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
Event ID 4740
Task Category User Account Management
Level Information
Keywords Audit Success
User N/A
Description A user account was locked out.
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


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
Description An account failed to log on.
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


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).

Focus on assets, not threats

As defenders, it is our job to make the attackers’ lot in life harder. Push them up the “pyramid of pain“. Be a hard target so they move on to a softer/easier one.

David Bianco_Pyramid of Pain v2

As we released the new “Attackers” dashboard feature in EventTracker 8.0, we found a lot of excitement that “threats” could be visualized on a global map, as they were detected in security data. Visualization is a key requirement for security analysts who often pore through mountains of data to uncover bad actors. As our SIEM Simplified team began to use this feature internally, one piece of feedback was immediately obvious — in very short order, the analysts lost interest in the “attackers” and started to focus on the targets instead.

EventTracker's Attackers Dashboard
EventTracker’s Attackers Dashboard

Analysts said, we care much less about the identity of the attacker (attribution is interesting to management — we are being attacked by bad guys in Beijing, Moscow, etc. — but pretty useless to defenders). After all, even the mighty U.S. Government dithers on proportionate response, even with their knowledge of attackers. So what is expected at our company that has far less resources?

In other words, focus on assets, not threats. Know more about attack methods — which port, application, vulnerability is being attacked — rather than if it’s Lee from Beijing or Ivan or Moscow or whoever.

In keeping with this focus, EventTracker 8.0 offers a filter to “pair” attackers with targets and a Targets Dashboard, which is now the favorite starting point for security analysts.

EventTracker's Targets Dashboard
EventTracker’s Targets Dashboard

This is what an effective security buyer does. After all, if attackers can simply switch attack vectors, they will. If they have to switch targets, you have disadvantaged them and pushed them up the pyramid of pain.

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?

Catching Hackers Living off the Land Requires More than Just Logs

If attackers can deploy a remote administration tool (RAT) on your network, it makes it so much easier for them. RATs make it luxurious for bad guys; it’s like being right there on your network. RATs can log keystrokes, capture screens, provide RDP-like remote control, steal password hashes, scan networks, scan for files and upload them back to home. So if you can deny attackers the use of RATs, you’ve just made life a lot harder for them.

We are getting better at catching so-called advanced persistent threats by detecting the malware they deploy on compromised systems. We can say this because experts are seeing more attackers “living off the land.” Living off the land means an attacker goes malware-free and instead relies on the utilities, scripting engines, command shells and other native resources available on systems where they gain an entry point.

By living off the land, they keep a much lower profile. They aren’t stopped as much by application control and whitelisting controls. There’s no malware for antivirus to detect.

And Windows provides plenty of native resources for this kind of attacker. (Linux and UNIX do too, but I’m focusing on Windows since client endpoints initially targeted by today’s attackers mostly run Windows.) You might be surprised how much you can do with just simple batch files, let alone PowerShell. And then there’s WMI. Both PowerShell and WMI provide a crazy amount of functionality. You can access remote systems and basically interface with any API of the operating system. You can open up network connections for “phoning home” to command and control servers, and more. This is all stuff that in years past required an EXE or DLL. Now you can basically do anything that a custom built EXE can do but without touching the file system which so much of our current security technology is based on.

How do you prevent attacks like this? PowerShell has optional security restrictions you can implement for preventing API access and limiting script execution to signed script files. With WMI it’s not as clear. Obviously, all the normal endpoint security technologies have a part to play.

But let’s focus on detection. It’s impossible to prevent everything and mitigate every vulnerability. So we can’t neglect detection. The challenge with detecting attackers that are living off the land is twofold. The activities you need to monitor:

  1. Aren’t found in logs
  2. Are happening on client endpoints

Both of these create big challenges. Let’s talk about #1 first. A.N. Ananth and I describe the types of activities that are clues to possible attacker living off the land in 5 Indicators of Evil on Windows Hosts using Endpoint Threat Detection and Response and I encourage you to watch that session which is full of good technical tips. But the point is that what you need to watch for isn’t in the Windows security log or other logs. Instead, detection requires a combination of file scanning, configuration checks, querying of running processes and so on — all stuff that requires code running on the local system or very powerful and complex remote access. If we were only talking about servers, we could consider deploying an agent. But to catch today’s threats, you need to be monitoring where they begin, which is on client endpoints — the desktops and laptops of your employees. And there’s no way to remotely reach into that many systems in real time, even if you overcame the technical hurdles of that kind of remote access. So that leaves agents, which always cause a degree of pushback.

But it’s time to stop calling them agents. Today what we need on endpoints are sensors. It’s a subtle but important shift in mindset. In the physical world, everyone understand the need for sensors, and that sensors have to be deployed where the condition is being monitored. If you want to know when someone enters your building at night, you need a sensor on every door. Likewise, if you want the earliest possible warning that your organizations have been compromised, you need a sensor on every endpoint.

So I encourage you to start thinking and speaking in terms of leveraging your endpoints as a sensor rather than yet another system that requires an agent. And look for security vendors that get this. EventTracker has done a great job of evolving their agent into a powerful and irreplaceable endpoint security agent that “sees” things that are just impossible to see any other way.

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.

How to Detect Low Level Permission Changes in Active Directory

We hear a lot about tracking privileged access today because privileged users like Domain Admins can do a lot of damage. But more importantly, if their accounts are compromised the attacker gets full control of your environment.

In line with this concern, many security standards and compliance documents recommend tracking changes to privileged groups like Administrators, Domain Admins and Enterprise Admins in Windows, and related groups and roles in other applications and platforms.

But in some systems you can also granularly delegate privileged access, ultimately giving someone the same level of authority as a Domain Admin, but “underneath the radar.” This is especially true in AD. This capability is a double-edged sword. It’s necessary if you are going to implement least privilege, but it also creates a way for privileged access to be granted inadvertently, or even maliciously in such a way that will go unnoticed unless you are specifically looking for it. Here’s how:

First you need to enable “Audit Directory Service Changes” on your domain controllers — probably using the Default Domain Controllers Policy GPO.

Then open Active Directory Users and Computers and enable Advanced Features under View. Next select the root of the domain and open Properties. Navigate the Audit tab of the domain’s Advanced Security Settings dialog shown below.


Add an entry for “Everyone” that audits “Modify permissions” on all objects like the entry highlighted above. At this point domain controllers will record Event ID 5136 whenever someone delegates authority of any object in the domain — whether an entire OU or a single-user account. Here’s an example event:

A directory service object was modified.


This event tells you that a MTG\pad-rsmith (that’s me) modified the permissions on the Scratch organizational unit in the MTG.local domain. nTSecurityDescriptor and “Value Added” tell us it was a permissions change. The Class field tells the type of object and DN gives us the distinguished name of the object whose permissions were changed. Subject tells us who made the change. I removed the lengthy text for Attribute Value because it’s too long to display and it’s in SDDL format which isn’t really human readable without a significant amount of effort. Technically, it does provide you with the full content of the OU’s new access control list (aka Security Descriptor) but it’s just not practical to try to decode it. It’s probably going to be faster to actually find the object in Active Directory Users and Computers and view its security settings dialog via the GUI.

So the Security Log isn’t perfect, but this method does give you a comprehensive audit trail of all permission changes and delegation within Active Directory. If you combine this with group membership auditing you’ll have a full picture of all changes that could impact privileged access in AD which is a key part of security and compliance.

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 gaddr10.0.0.187/53 laddr
  2. Mar 12 12:00:08 server2 rcd[308]: id=304 COMPLETE ‘Downloading https://server2/data/red-carpet.rdf’time=0s (failed)
  3. – – [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
    ReadData (or ListDirectory)
    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.