Download the Report
Advanced Threat Protection
Download the Datasheet
Let's Go Threat Hunting: Gain Visibility and Insight into Potential Threats and Risks
Download the Whitepaper
Bracing for the Tidal Wave of Data Privacy Compliance in America
View Recent Catches
Catch More Threats
April 11, 2013
Did you see the NY Times review by John Broder, which was critical about the Tesla Model S? Tesla CEO Elon Musk was not pleased. They are not arguing over interpretations or anecdotal recollections of experiences, instead they are arguing over basic facts — things that are supposed to be indisputable in an environment with cameras, sensors and instantly searchable logs.
The conflicting accounts — both described in detail — carry a lesson for those of us involved in log interpretation. Data is supposed to be the authoritative alternative to memory, which is selective in its recollection. As Bianca Bosker said, “In Tesla-gate, Big Data hasn’t made good on its promise to deliver a Big Truth. It’s only fueled a Big Fight.”
This is a familiar scenario if you have picked through logs as a forensic exercise. We can (within limitations) try and answer four of the five W questions – Who, What, When and Where, but the fifth one -Why- is elusive and brings the analyst of the realm of guesswork.
The Tesla story is interesting because interested observers are trying to deduce why the reporter was driving around the parking lot – to find the charger receptacle or to deliberately drain the battery and make for a bad review. Alas the data alone cannot answer this question.
In other words, relying on data alone, big data included, to plumb human intention is fraught with difficulty. An analyst needs context.
April 03, 2013
In Jacobellis v. Ohio (1964), Justice Potter Steward was quoted as saying, “I don’t know what porn is, but I’ll know it when I see it.” This is not dissimilar to the position that many business leaders confront the concept of “risk”.
When a business leader can describe and identify the risk they are willing to accept, then the security team can put appropriate controls in place. Easy to say, but so very hard to do. It’s because the quantification and definition of risk varies widely depending on the person, the business unit, the enterprise and also the vertical industry segment.
What is the downside of not being able to define risk? It leaves the security team guessing about what controls are appropriate. Inadequate controls expose the business to leakage and loss, whereas onerous controls are expen$ive and even offensive to users.
What do you do about it? Communication between the security team and business stakeholders is essential. We find that scenarios that demonstrate and personalize the impact of risk resonate best. It’s also useful to have a common vocabulary as the language divide between the security team and business stakeholders is a consistent problem. Where possible, use terminology that is already in use in the business instead of something from a standard or framework.
March 28, 2013
March 20, 2013
5 telltale signs that your data security is failing and what you can do about it:
1) Security controls are not proportional to the business value of data
Protecting every bit of data as if it’s a gold bullion in Ft. Knox is not practical. Controls complexity (and therefore cost) must be proportional to the value of the items under protection. Loose change belongs on the bedside table; the crown jewels belong in the Tower of London. If you haven’t classified your data to know which is which, then the business stakeholders have no incentive to be involved in its protection.
2) Gaps between data owners and the security team
Data owners usually only understand business processes and activities and the related information – not the “data”. Security teams, on the other hand, understand “data” but usually not its relation to the business, and therefore its criticality to the enterprise. Each needs to take a half step into the others’ domain.
3) The company has never been penalized
Far too often, toothless regulation encourages a wait-and-see approach. Show me an organization that has failed an audit and I’ll show you one that is now motivated to make investments in security.
4) Stakeholders only see value in sharing, not the risk of leakage
Data owners get upset and push back against involving security teams in the setup of access management. Open access encourages sharing and improves productivity, they say. It’s my data, why are you placing obstacles in its usage? Can your security team effectively communicate the risk of leakage in terms that the data owner can understand?
5) Security is viewed as a hurdle to be overcome
How large is the gap between the business leaders and the security team? The farther apart they are, the harder it is to get support for security initiatives. It helps to have a champion, but over-dependence on a single person is not sustainable. You need buy-in from senior leadership.
March 15, 2013
March 13, 2013
I think one of the most underutilized features of Windows Auditing and the Security Log are Process Tracking events. In Windows 2003/XP you get these events by simply enabling the Process Tracking audit policy. In Windows 7/2008+ you need to enable the Audit Process Creation and, optionally, the Audit Process Termination subcategories which you’ll find under Advanced Audit Policy Configuration in group policy objects.
March 06, 2013
In this blog post, Mike Rothman described the quandary facing the midsize business. With a few hundred employees, they have information that hackers want to and try to get but not the budget or manpower to fund dedicated IT Security types, nor the volume of business to interest a large outsourcer. This puts them in no-man’s land with a bull’s-eye on their backs. Hackers are highly motivated to monetize their efforts and will therefore cheerfully pick the lowest hanging fruit they can get. It’s a wicked problem to be sure and one that we’ve been focused on addressing in our corner of the IT Security universe for some years now.
Our solution to this quandary is called SIEM SimplifiedSM and stems from the acceptance that as a vendor we could go developing all sorts of bells and whistles to our product offering only to see an ever shrinking percent of users actually use them in the manner they were designed. Why? Simply put, who has the time? Just as Mike says, our customers are people in mid-size businesses, wearing multiple hats, fighting fires and keeping things operational. SIEM Simplified is the addition of an expert crew at the EventTracker Control Center, in Columbia MD that does the basic blocking and tackling which is the core ingredient if you want to put points on the board. By sharing the crew across multiple customers, it reduces the cost for customers and increases the likelihood of finding the needle in the haystack. And because it’s our bread and butter, we can’t afford to get tired or take a vacation or fall sick and fall behind.
A decade-long focus on this problem as it relates to mid-size businesses has allowed us to tailor the solution to such needs. We use the behavior module to quickly spot new or out-of-ordinary patterns, and a wealth of existing reports and knowledge to do the routine but essential legwork of log review. Mike was correct is pointing out that “folks in security no-man’s land need …. an advisor to guide them … They need someone to help them prioritize what they need to do right now.” SIEM Simplified delivers. More information here.
February 27, 2013
Online shopping continues to bring more and more business to “e-tailers.” Comscore says there was a 16% increase in holiday shopping this past season over the previous season. Some of this is attributed to “recommendations” that are helpfully shown by the giants of the game such as Amazon.
Here is how Amazon describes its recommendation algorithm. “We determine your interests by examining the items you’ve purchased, items you’ve told us you own items you’ve rated, and items you’ve told us you like. We then compare your activity on our site with that of other customers, and using this comparison, are able to recommend other items that may interest you.”
Did you know that EventTracker has its own recommendation engine? It’s called Behavior Correlation and is part of the EventTracker Enterprise. Just as Amazon, learns about your browsing and buying habits and uses it to “suggest” other items, so also, EventTracker auto-learns what is “normal” in your enterprise during an adaptive learning period. This can be as short as 3 days or as long as 15 days depending on the nature of your network. In this period, various items such as IP addresses, users, administrators, process names machines, USB serial numbers etc. are learned. Once learning is complete, data from the most recent period is compared to the learned behavior to pinpoint both unusual activities as well as those never-before-seen. EventTracker then “recommends” that you review these to determine if they point to trouble.
Learning never ends, so the baseline is adaptive, refreshing itself continuously. User defined rules can also be implemented wherein the comparison periods are not learned but specified, and comparisons performed not once a day but as frequently as once a minute.
If you shop online and feel drawn to a “recommendation”, pause to reflect how this concept can also improve your IT security by looking at logs.
February 22, 2013
Based on early media reports, the Cyber Security executive order would seem to portend voluntary compliance on the part of U.S. based companies to implement security standards developed in concert with the federal government. Setting aside the irony of an executive order to voluntarily comply with standards that are yet to be developed, how should private and public sector organizations approach cyber security given today’s exploding threatscape and limited information technology budgets? How best to prepare for more bad guys, more threats, more imposed standards with less people, time and money?
Back to basics. First let’s identify the broader challenges: of course you’re watching the perimeter with every flavor of firewall technology and multiple layers of IDS, IPS, AV and other security tools. But don’t get too comfortable: every organization that has suffered a damaging breach had all those things too. Since every IT asset is a potential target, every IT asset must be monitored. Easy to describe, hard to implement. Why?
Challenge number one: massive volumes of log data. Every organization running a network with more than 100 nodes is already generating millions of audit and event logs. Those logs are generated by users, administrators, security systems, servers, network devices and other paraphernalia. They generate the raw data that tracks everything going on from innocent to evil, without prejudice.
Challenge number two: unstructured data. Despite talk and movement toward audit log standards, log data remains widely variable with no common format across platforms, systems and applications, and no universal glossary to define tokens and values. Even if every major IT player from Microsoft to Oracle (and HP and Cisco), along with several thousand other IT organizations were to adopt uniform, universal log standards today, we would still have another decade or two of the dreaded “legacy data” with which to contend.
Challenge number three: cryptic or non-human readable logs. Unstructured data is difficult enough, but further adding to the complexity is that most of the log data content and structure are defined by developers for developers or administrators. Don’t assume that security officers and analysts, senior management, help desk personnel or even tenured system administrators can quickly and accurately glance at a log and immediately understanding its relevance or more importantly what to do about it.
Solution? Use what you already have more wisely. Implement a log monitoring solution that will ingest all of the data you already generate (and largely ignore until after you discover there’s a real problem), process it in real-time using built-in intelligence, and present the analysis immediately in the form of alerts, dashboards, reports and search capabilities. Take a poorly designed and voluminous asset (audit logs) and turn it into actionable intelligence. It isn’t as difficult as it sounds, though it require rigorous discipline and a serious time commitment.
Cyber criminals employ the digital equivalent of what our military refers to as an “asymmetrical tactic.” Consider a hostile emerging super power in Asia that directly or indirectly funds a million cyber warriors at the U.S. equivalent of $10 a day; cheap labor in a global economy. No organization, not even the federal government, the world’s largest bank or a 10 location retailer, has unlimited people, time and money to defend against millions of bad guys attacking on a much lower (asymmetrical) operational budget.
February 13, 2013
On a recent flight returning from an engagement with a client, my seating companion and I exchanged a few words as we settled into the flight before donning and turning to the iPod music and games used to distract ourselves from the hassles of travel. He was a cardiologist, and introduced himself as such, before quickly describing his job as basically ‘a glorified plumber’. We both chuckled knowing that while sharing fundamentals in basic concepts, there was much more to cardiology than managing and controlling flow. BTW, my own practical plumbing experiences convinced me of the value of a good plumber.
February 10, 2013
The value proposition of our SIEM Simplified offering is that you can leave the heavy lifting to us. What is undeniable is that getting value from SIEM solutions requires patient sifting through millions of logs, dozens of reports and alerts to find nuggets of value. It’s quite similar to detective work.
But does that not mean you are somehow giving up power? Letting someone else get a claw hold in your domain?
Valid question, but consider this from Nilofer Merchant who says “In the Social Era, value will be (maybe even already is) no longer created primarily by people who work for you or your organization“.
Isn’t power about being the boss?
The Social Era has disrupted the traditional view of power which has always been your title, span of control and budget. Look at Wikipedia or Kickstarter where being powerful is about championing an idea. With SIEM Simplified, you remain in control, notified as necessary, in charge of any remediation.
Aren’t I paid to know the answer?
Not really. Being the keeper of all the answers has become less important with the rise of fantastic search tools and the ease of sharing, as compared to say even 10 years ago. Merchant says “When an organization crowns a few people as chiefs of answers, it forces ideas to move slowly up and down the hierarchy, which makes the organization resistant to change and less competitive. The Social Era raises the pressure on leaders to move from knowing everything to knowing what needs to be addressed and then engaging many people in solving that, together.” Our staff does this every day, for many different environments. This allows us to see the commonalities and bring issues to the fore.
Does it mean blame if there is failure and no praise if it works?
In a crowd sourcing environment, there are many more hands in every pie. In practice, this leads to more ownership from more people than the other way around. Consider Wikipedia as an example of this. It does require different skills, collaborating instead of commanding, sharing power rather than hoarding it. After all, we are only successful, if you are. Indeed, as a provider of the service, we are always mindful that this applies to us more than it does you.
As a provider of services, we see clearly that the most effective engagements are the ones where we can avoid the classic us/them paradigm and instead act as a badgeless team. The Hubble Space Telescope is an excellent example of this type of effort.
It’s a Brave New World, and it’s coming at you, ready or not.
February 06, 2013
Mike Wu writing in Tech Crunch observed that in all realistic data sets (especially big data), the amount of information one can extract from the data is always much less than the data volume (see figure below): information data.
In his view, given the above, the value of big data is hugely exaggerated. He then goes on to infer that this is actually a strong argument for why we need even bigger data. Because the amount of valuable insights we can derive from big data is so very tiny, we need to collect even more data and use more powerful analytics to increase our chance of finding them.
Now machine data (aka log data) is certainly big data, and it is certainly true that obtaining insights from such dataset’s is a painstaking (and often thankless) job, but I wonder if this means we need even more data. Methinks we need to be able to better interpret the big data set and its relevance to “events”.
Over the past two years, we have been deeply involved in “eating our own dog food” as it were. At multiple EventTracker installations that are nationwide in scope, and span thousands of log sources, we have been working to extract insights for presentation to the network owners. In some cases, this is done with a lot of cooperation from the network owner and we have a good understanding of IT assets and the actors who use/abuse them. We find that with such involvement we are better able to risk prioritize what we observe in the data set and map to business concerns. In other cases where there is less interaction with the network owner and we know less about the actors or the relative criticality of assets, then we fall back on past experience and/or vendor-provided info as to what is an incident. It is the same dataset in both cases but there is more value in one case than the other.
To say it another way, to get more information from the same data we need other types of context to extract signal from noise. Enabling logging at a more granular level from the same devices thereby generating an ever bigger dataset won’t increase the signal level. EventTracker can merge change audit data netflow information as well as vulnerability scan data to enable a greater signal-to-noise ratio. That is a big deal.
January 30, 2013
Small businesses around the world tend to be more innovative and cost-conscious. Most often, the owners tend to be younger and therefore more attuned to being online. The efficiencies that come from being computerized and connected are more obvious and attractive to them. But we know that if you are online then you are vulnerable to attack. Are these small businesses too small for hackers to care?
Two recent reports say no.
The UK the Information Security Breaches survey 2012 survey results published by PWC shows:
From the US, the 2012 Verizon data breach report shows:
Lesson learned? Small may be beautiful, but in the interconnected world we live in, not too small to be hacked. Protect thyself – start simple by changing remote access credentials and enabling a firewall, monitor and mine your logs. ‘Nuff said.
January 23, 2013
Is this true for you? That your smartphone has merged your private and work lives. Smartphones now contain—by accident or by design—a wealth of information about the businesses we work for.
If your phone is stolen, the chance of getting it back approaches zero. How about lost in an elevator or the back seat of a taxi? Will it be returned? More importantly, from our point of view, what about the info on it – the corporate info?
Earlier this year, the Symantec HoneyStick project conducted an experiment by “losing” 50 smartphones in five different cities: New York City; Washington D.C.; Los Angeles; San Francisco; and Ottawa, Canada. Each had a collection of simulated corporate and personal data on them, along with the capability to remotely monitor what happened to them once they were found. They were left in high traffic public places such as elevators, malls, food courts, and public transit stops.
The corporate related apps included remote access as well as email accounts. What is the lesson for corporate IT staff?
See our webinar, ‘Using Logs to Deal With the Realities of Mobile Device Security and BYOD.’
January 17, 2013
The headlines are ablaze with the news of a new zero-day vulnerability in Java which could expose you to a remote attacker.
The Department of Homeland Security recommends disabling Java completely and many experts are apparently concurring. Crisis communications 101 says maintain high-volume, multi-channel communications but there is a strange silence from Oracle, aside of the announcement of a patch for said vulnerability.
Allowing your opponents to define you is a bad mistake as any political consultant will tell you. Today it’s Java, tomorrow, some other widely used component. The shrillness of the calls also makes me wonder why the hullabaloo? Upset by the Oracle stewardship of Java, perhaps?
So what should you make of the “disable Java” calls echoing across Cyberia? Personally I think it’s bad advice, assuming you can even take the advice in the first place. Java is widespread in server side applications (usually enterprise software) and embedded devices. There is probably no easy way to “upgrade” a heart pump or elevator control or a POS system. As far as server side, this may be easier but spare a thought to backward compatibility and business applications that are “certified” on older browsers. Pause a moment, the vulnerability becomes exposed when you visit a malicious website which can then take advantage of the flaw and get on your machine.
Instead of disabling Java and thereby possibly breaking critical functionality, why don’t you limit access to outside websites instead? This is easily done by configuring proxy servers (good for desktops or mobile situations) or limiting devices to a subnet that only has access to the trusted internal hosts (this can work for bar code scanners or manufacturing equipment). This limits your exposure. Proxy server filtering at the internet perimeter is done by matching the user agent string. This is also a good way to limit those older insecure browsers that must be present for internal applications from accessing the outside and potentially being equally a source of infection in the enterprise.
This is a serious issue that merits a thoughtful response, not a panicked rush to comply and cripple your enterprise.
January 09, 2013
I often encounter a dangerous misconception about the Windows Security Log: the idea that you only need to monitor domain controller logs. Domain controller security logs are absolutely critical to security but they are only a portion of your overall audit trail. Member server and workstation logs are really just as important and I’m going to focus this article on the top 4 questions you can only answer with workstation logon/logoff events.
For your workstations to generate these events you need to enable at least the following audit policy. Remember that XP is configured with the legacy 9 audit categories while Windows 7 and 8 should be configured with audit subcategories under Advanced Audit Policy in group policy objects:
January 08, 2013
A New Year’s resolution is a commitment that a person makes to one or more personal goals, projects, or the reforming of a habit.
Here are mine:
1) Shed those extra pounds of logs:
Log retention is always a challenge — how much to keep, for how long? Keep them too long and they are just eating away storage space. Pitch them mercilessly and keep wondering if you will need them. For guidance, look to any regulation that may apply. PCI-DSS says 365 days, for example; NIST 800-92 unhelpfully says “This should be driven primarily by organizational policies” and then goes on to classify logs into system, infrastructure and application levels. Bottom line, use your judgment because you know your environment best.
2) Exercise your log analysis muscles regularly
As the Verizon Data Breach report says year in and year out, the bad guys are hoping that you are not collecting logs, and if you are, that you are not reviewing them. More than 96% of all attacks were not highly difficult and were avoidable (at least in hindsight) without difficult or expensive countermeasures. Easier said than done, isn’t it? Consider co-sourcing the effort.
3) Play with existing toys before buying new ones
Know what configuration assessment is? It’s applying secure configurations to existing equipment. Agencies such as NIST, CIS and DISA provide detailed guidelines. Vendors such as Microsoft provide hardening guides. It’s a question of applying them to existing hardware. This reduces attack surface and contributes greatly to a more secure posture. You already have the equipment, just apply the secure configuration. EventTracker can help measure results.
Happy New Year.
December 31, 2012
December 19, 2012
“The beginning of a new year marks a time of reflection on the past and anticipation of the future. The result for analysts, pundits and authors is a near irresistible urge to identify important trends in their areas of expertise…” (from our January newsletter) We made a lot of predictions this past year and now it’s time to review them and assess our accuracy.
December 18, 2012
In January 2010 the U.S. Senate was locked in a sharp debate about the country’s debt and deficit crisis. Unable to agree on a course of action, some Senators proposed the creation of a fiscal commission that would send Congress a proposal to address the problem with no possibility of amendments. It was chaired by former Senator, Alan Simpson, and former White House chief of staff, Erskine Bowles.
Darrel West and Ashley Gabriele of Brookings examined the leadership lessons in this article. I was struck by the application of some of the lessons to the SIEM problem.
1) Stop Fantasizing About Easy Fixes
Cutting waste and fraud is not sufficient to address long-term debt and deficit issues. To think that we can avoid difficult policy choices simply by getting rid of wasteful spending is a fantasy. It’s also tempting to think that the next Cisco firewall, Microsoft OS or magic box will solve all security issues; that the hard work of reviewing logs, changes and assessing configuration will not be needed. It’s high time to stop fantasizing about such things.
2) Facts Are Informative
Senator Daniel Patrick Moynihan famously remarked that “everyone is entitled to his own opinion, but not to his own facts.” This insight often is lost in Washington D.C. where leaders invoke “facts” on a selective or misleading basis. The Verizon Data Breach report has repeatedly shown that attacks are not highly difficult, that most breaches took weeks or more to be discovered and that almost all were avoidable through simple controls. We can’t get away from it — looking at logs is basic and effective.
3) Compromise Is Not a Dirty Word
One of the most challenging aspects of the contemporary political situation is how bargaining, compromise, and negotiation have become dirty words. Do you have this problem in your Enterprise? Between the Security and Compliance teams? Between the Windows and Unix teams? Between the Network and Host teams? Is it preventing you from evaluating and agreeing on a common solution? If yes, this lesson is for you — compromise is not a dirty word.
4) Security and Compliance Have Credibility in Different Areas
On fiscal issues, Democrats have credibility on entitlement reform because of their party’s longstanding advocacy on behalf of Social Security, Medicare, and Medicaid. Meanwhile, Republicans have credibility on defense issues and revenue enhancement because of their party’s history of defending the military and fighting revenue increases. In our world, the Compliance team has credibility on regular log review and coverage of critical systems, while the Security team has credibility on identifying obvious and subtle threats (out-of-ordinary behavior). Different areas, all good.
5) It’s Relationships, Stupid!
Commission leaders found that private and confidential discussions and trust-building exercises were important to achieving the final result. They felt that while public access and a free press were essential to openness and transparency, some meetings and most discussions had to be held behind closed doors. Empower the evaluation team to have frank and open discussion with all stakeholders — including those from Security, Compliance, Operations and Management. Such a consensus built in advance leads to a successful IT project.
December 12, 2012
The newspapers are full of stories of the latest attack. Then vendors rush to put out marketing statements glorifying themselves for already having had a solution to the problem, if only you had their product/service, and the beat goes on.
Pause for a moment and compare this to health scares. The top 10 scares according to ABC News include Swine Flu (H1N1), BPA, Lead paint on toys from China, Bird Flu (H5N1) and so on. They are, no doubt, scary monsters but did you know that the common cold causes 22 million school days to be lost in the USA alone?
In other words, you are better off enforcing basic discipline to prevent days lost from common infections than stockpiling exotic vaccines. The same is true in IT security. Here then, are the top 5 attack vectors of all time. Needless to say these are not particularly hard to execute, and are most often successful simply because basic precautions are not in place or enforced. The Verizon Data Breach Report demonstrates this year in and year out.
1. Information theft and leakage
Personally Identifiable Information (PII) data stolen from unsecured storage is rampant. The Federal Trade Commission says 21% of complaints are related to identity theft and have accounted for 1.3M cases in 2009/10 in the USA. The 2012 Verizon DBIR shows 855 incidents and 174M compromised records.
Lesson learned: Implement recommendations like SANS CAG or PCI-DSS.
2. Brute force attack
Hackers leverage cheap computing power and pervasive broadband connectivity to breach security. This is a low cost, low tech attack that can be automated remotely. It can be easily detected and defended against, but it requires monitoring and eyes on the logs. It tends to be successful because monitoring is absent.
Lesson learned: Monitor logs from firewalls and network devices in real time. Set up alerts which are reviewed by staff and acted upon as needed. If this is too time consuming, then consider a service like SIEM Simplified.
3. Insider breach
Staff on the inside is often privy to a large amount of data and can cause much larger damage. The Wikileaks case is the poster child for this type of attack.
4. Process and Procedure failures
It is often the case that in the normal course of business, established process and procedures are ignored. Unfortunate coincidences can cause problems. Examples of this are e-mailing interim work products to personal accounts, taking work home in USB sticks and then losing them, sending CDROMs with source code by mail and then they are lost, etc.
Lesson learned: Reinforce policies and procedures for all employees on a regular basis. Many US Government agencies require annual completion of a Computer Security and Assessment Test. Many commercial banks remind users via message boxes in the login screen.
5. Operating failures
This includes oops moments, such as backing up data to the wrong server and sending backup data off-site where it can be restored by unauthorized persons.
Lesson learned: Review procedures and policies for gaps. An external auditor can be helpful in identifying such gaps and recommending compensating controls to cover them.
December 05, 2012
Did you know that big data is old news in the area of financial derivatives? O’Connor & Associates was founded in 1977 by mathematician Michael Greenbaum, who had run risk management for Ed & Bill O’Connor’s options trading firm. What made O’Connor and Associates successful was the understanding that expertise is far more important than any tool or algorithm. After all, absent expertise, any tool can only generate gibberish; perfectly processed and completely logical, of course, but still gibberish.
Which brings us back to the critical role played by the driver of today’s enterprise tools. These tools are all full featured and automate the work of crushing an entire hillside of dirt to locate tiny grams of gold — but “got human”? It comes back to the skilled operator who knows how and when to push all those fancy buttons. Of course deciding which hillside to crush is another problem altogether.
This is a particularly difficult challenge for midsize enterprises which struggle with SIEM data; billions of logs, change and configuration data all now available thanks to that shiny SIEM you just installed. What does it mean? What are you supposed to do next? Large enterprises can afford a small army of experts to extract value, whereas the small business can ignore the problem completely but for the midsize enterprises, it’s the worst of all worlds – Compliance regulations, tight budgets, lean staff and the demand for results?
This is why our SIEM Simplified offering was created: to allow customers to outsource the heavy lifting part of the problem while maintaining control over the critical and sensitive decision making parts. At the EventTracker Control Center (ECC), our expert staff watches your incidents and reviews log reports daily, and alert you to those few truly critical conditions that warrant your attention. This frees up your staff to take care of things that cannot be outsourced. In addition, since the ECC enjoys economies of scale, this can be done at lesser cost than do-it-yourself. This has the advantage of inserting the critical human component back into the equation but at a price point that is affordable.
As Grady Booch observed “A fool with a tool is still a fool.”
November 29, 2012
Troubleshooting problems with enterprise applications and services are often exercises in frustration for IT and business staff. The reasons are well documented – complex architectures, disparate, unintegrated monitoring solutions, and minimal coordination between technology and product experts while attempting to pinpoint and resolve problems under the pressures of an escalating negative impact of delays and/or downtime on revenues, customer satisfaction and the delivery of services.
October 24, 2012
I’ve spent the last 20 years analyzing the Information Technologies market. My work with vendors has ranged from developing business strategies and honing messaging to defining product requirements and identifying significant trends. My work with IT enterprise decision-makers has been to help define requirements, identify and evaluate alternatives, and recommend solutions, etc. We’ve always worked closely with our clients to understand first what they are trying to accomplish, then providing the advice, support and services that we believe will be most effective in achieving those goals.
October 23, 2012
In the spirit of the Washington Posts’ regular column, “5 Myths,” here we “challenge everything you think you know” about PCI-DSS Compliance.
1. One vendor and product will make us compliant
While many vendors offer an array of services and software which target PCI-DSS, no single vendor or product fully addresses all 12 of the PCI-DSS v2.0 requirements. Marketing departments often position offerings in such a manner as to give the impression of a “silver bullet.” The PCI Security Standards Council warns against reliance on a single product or vendor and urges a security strategy that focuses on the big picture.
2. Outsourcing card processing makes us compliant
Outsourcing may simplify payment card processing but does not provide automatic compliance. PCI-DSS also calls for policies and procedures to safeguard cardholder transactions and data processing when you receive them — for example, chargebacks or refunds. You should request an annual certificate of compliance from the vendor to ensure that their applications and terminals are compliant.
3. PCI is too hard, requires too much effort
The 12 requirements can seem difficult to understand and implement to merchants without a dedicated IT department, however these requirements are basic steps for good security. The standard offers the alternative of compensating controls, if needed. The market is awash with many products and services to help merchants achieve compliance. Also consider that the cost of non-compliance can often be higher, including fines, legal fees, lost business and reputation.
4. PCI requires us to hire a Qualified Security Assessor (QSA)
PCI-DSS offers the option of doing a self-assessment with officer sign-off if your merchant bank agrees. Most large retailers prefer to hire a QSA because they have complex environments, and QSAs provide valuable expertise including the use of compensating controls.
5. PCI compliance will make us more secure
Security exploits are non-stop and an ever escalating war between the bad and good guys. Achieving PCI-DSS compliance, while certainly a “brick in the wall” of your security posture, is only a snapshot in time. “Eternal vigilance is the price of liberty,” said Wendell Phillips.
October 17, 2012
If you could offer your IT Security team 100 times more data than they currently collect – every last log, every configuration, every single change made to every device in the entire enterprise at zero cost – would they be better off? Would your enterprise be more secure? Completely compliant? You already know the answer – not really, no. In fact, some compliance-focused customers tell us they would be worse off because of liability concerns (you had the data all along but neglected to use it to safeguard my privacy), and some security focused customers say it will actually make things worse because we have no processes to effectively manage such archives.
As Micheal Schrage noted, big data doesn’t inherently lead to better results. Organizations must grasp that being “big data-driven requires more qualified human judgment than cloud-based machine learning.” For big data to be meaningful, it has to be linked to a desirable business outcome, or else executives are just being impressed or intimidated by the bigness of the data set. For example, IBMs DeepQA project stores petabytes of data and was demonstrated by Watson, the successful Jeopardy playing machine – that is big data linked clearly to a desirable outcome.
In our corner of the woods, the desirable business outcomes are well understood. We want to keep bad guys out (malware, hackers), learn about the guys inside that have gone bad (insider threats), demonstrate continuous compliance, and of course do all this on a leaner, meaner budget.
Big data can be an embarrassment of riches if linked to such outcome. But note the emphasis on “qualified human judgment.” Absent this, big data may be just an embarrassment. This point underlines the core problem with SIEM – we can collect everything, but who has the time or rule-set to make the valuable stuff jump out? If you agree, consider a managed service. It’s a cost effective way to put big data to work in your enterprise today – clearly linked to a set of desirable outcomes.
October 10, 2012
The advent of the big data era means that analyzing large, messy, unstructured data will increasingly form part of everyone’s work. Managers and business analysts will often be called upon to conduct data-driven experiments, to interpret data, and to create innovative data-based products and services. To thrive in this world, many will require additional skills. In a new Avanade survey, more than 60 percent of respondents said their employees need to develop new skills to translate big data into insights and business value.
Ready and willing to experiment with your log and SIEM data? Managers and security analysts must be able to apply the principles of scientific experimentation to their log and SIEM data. They must know how to construct intelligent hypotheses. They also need to understand the principles of experimental testing and design, including population selection and sampling, in order to evaluate the validity of data analyses. As randomized testing and experimentation become more commonplace, a background in scientific experimental design will be particularly valued.
Adept at mathematical reasoning? How many of your IT staff today are really “numerate” — competent in the interpretation and use of numeric data? It’s a skill that’s going to become increasingly critical. IT Staff members don’t need to be statisticians, but they need to understand the proper usage of statistical methods. They should understand how to interpret data, metrics and the results of statistical models.
Able to see the big (data) picture? You might call this “data literacy,” or competence in finding, manipulating, managing, and interpreting data, including not just numbers but also text and images. Data literacy skills should be widespread within the IT function, and become an integral aspect of every function and activity.
Jeanne Harris blogging in the Harvard Business Review writes, “Tomorrow’s leaders need to ensure that their people have these skills, along with the culture, support and accountability to go with it. In addition, they must be comfortable leading organizations in which many employees, not just a handful of IT professionals and PhDs in statistics, are up to their necks in the complexities of analyzing large, unstructured and messy data.
“Ensuring that big data creates big value calls for a reskilling effort that is at least as much about fostering a data-driven mindset and analytical culture as it is about adopting new technology. Companies leading the revolution already have an experiment-focused, numerate, data-literate workforce.”
If this presents a challenge, then co-sourcing the function may be an option. The EventTracker Control Center here at Prism offers SIEM Simplified, a service where trained and expert IT staff perform the heavy lifting associated with big data analysis, as it relates to SIEM data. By removing the outliers and bringing patterns to your attention at greater efficiencies because of scale, focus and expertise, you can focus on the interpretation and associated actions.
October 03, 2012
1) Lust: Be not easily lured by the fun, sexy demo. It always looks fantastic when the sales guy is driving. How does it work when you drive? Better yet, on your data?
2) Gluttony: Know thy log volume. When thee consumeth mucho more raw logs than thou expected, thou shall pay and pay dearly. More SIEM budgets die from log gluttony than starvation.
3) Greed: Pure pursuit of perfect rules is perilous. Pick a problem you’re passionate about, craft monitoring, and only after it is clearly understood do you automate remediation.
4) Sloth: The lazy shall languish in obscurity. Toilers triumph. Use thy SIEM every day, acknowledge the incidents, review the log reports. Too hard? No time you say? Consider SIEM Simplified.
5) Wrath: Don’t get angry with the naysayers. Attack the problem instead. Remember “those who can, do; those who cannot, criticize.” Democrats: Yes we can v2.0.
6) Envy: Do not copy others blindly out of envy for their strategy. Account for your differences (but do emulate best practices).
7) Pride: Hubris kills. Humility has a power all its own. Don’t claim 100% compliance or security. Rather you have 80% coverage but at 20% cost and refining to get the rest. Republicans: So sayeth Ronald Reagan.
September 26, 2012
Our SIEM Simplified offering is manned by a dedicated staff overseeing the EventTracker Control Center (ECC). When a new customer comes aboard, the ECC staff is tasked with getting to know the new environment, identifying which systems are critical, which applications need watching, and what access controls are in place, etc. In theory, the customer would bring the ECC staff up to speed (this is their network, after all) and keep them up to date as the environment changes. Reality bites and this is rarely the case. More commonly, the customer is unable to provide the ECC with anything other than the most basic of information.
How then can the ECC “learn” and why is this problem interesting to SIEM users at large?
Let’s tackle the latter question first. A problem facing new users at a SIEM installation is that they get buried in getting to know the baseline pattern and the enterprise (the very same problem the ECC faces). See this article from a practitioner.
So it’s the same problem. How does the ECC respond?
Short answer: By looking at behavior trends and spotting the anomalies.
Long answer: The ECC first discovers the network and learns the various device types (OS, application, network devices etc.). This is readily automated by the StatusTracker module. If we are lucky, we get to ask specific the customer questions to bolster our understanding. Next, based on this information and the available knowledge packs within EventTracker, we schedule suitable daily and weekly reports and configure alerts. So far, so good, but really no cigar. The real magic lies in taking these reports and creating flex reports where we control the output format to focus on parameters of value that are embedded within the description portion of the log messages (this is always true for syslog formatted messages but also for Windows style events). When these parameters are trended in a graph, all sorts of interesting information emerges.
In one case, we saw that a particular group of users was putting their passwords in the username field then logging in much more than usual — you see a failed login followed by a successful one; combine the two and you have both the username and password. In another case, we saw repeated failed logon after hours from a critical IBM i-Series machine and hit the panic button. Turns out someone left a book on the keyboard.
Takeaway: Want to get useful value from your SIEM but don’t have gobs of time to configure or tune the thing for months on end? Think trending behavior, preferably auto-learned. It’s what sets EventTracker apart from the search engine based SIEMs or from the rules based products that need an expen$ive human analyst chained to the product for months on end. Better yet, let the ECC do the heavy lifting for you. SIEM Simplified, indeed.
September 20, 2012
Despite its significant costs and a mixed record of success, the compliance-related load imposed on today’s enterprise has yet to decrease. Current trends driven by government legislative efforts, and adopted at the executive level, favor the continuing proliferation of monitoring and reporting in operations, decision-making and service delivery. Even if existing legislation is repealed, it is not certain that compliance edicts will cease.
See EventTracker in action!
Join our next live demo December 4th at 2:00 p.m. EST.