Posts tagged: 'network security'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.
http://blog.logrhythm.com/tags/network-security/feedIn the belly of the whale…
I recall a story from infant school. It described a holy man being begged by frightened mariners during a storm to pray for calm waters. He refused, suggesting that it was better not to wait until the storm, but to have acted before the clouds gathered.
To a similar point, ‘feast or famine’ is a favourite phrase of mine. I use it to describe folly of all kinds. But it’s a great way to highlight a major organisational shortcoming too – the side-lining of known important activities in favour of short term pressures. This is a tactic everyone uses though, surely? Well, in the security field it’s not working and hasn’t worked for years.
“Little and often’ is another favourite. I use it to describe a more virtuous method. It seems that whether you’re seeking to keep fit, preparing for an important event or even keeping on top of expenses, it’s a phrase that describes desirable behaviour. For many organisations, security spending has been far more ‘feast or famine’ than ‘little and often’, certainly as long as I have been in the industry anyway. Could this be about to change?
It all used to be about compliance. Security-related expenditure, that is. As long as the compliance box was ticked, the CFO’s job was safe, and the operations team could avoid getting yelled at in review meetings. But look at the last three months – it seems like the highest profile, most trusted brands are haemorrhaging customer information, credit card details and intellectual property to hackers. I’m not using those terms licentiously either – RSA, Sony and even the X-Factor database have been compromised. Those three events alone could add up to nearly half a billion compromised records. Does this mean compliance measures are not working? Well, the recent Verizon report suggests that where breaches have occurred, an overwhelming percentage of the companies that should have been PCI compliant, weren’t. 89% in fact. But these recent breaches were all despite compliance systems in being place, which seems to increasingly be the case.
What does this mean in terms of brand confidence? Here’s an example. I spend a lot of money with Amazon annually. In fact, I transact with them twenty or thirty times a year. Their customer service is every bit as good as people say. But, do you think Barnes and Noble or Play.com would get my business if Amazon lost my credit card number? You bet they would. Maybe this is where security is at an inflexion point. Are we at the stage, where organisations have to make ‘pre-sale’ commitments to customers about the safety of their data? Would I move suppliers in favour of someone who offered guarantees as to the safety of my personal information? Maybe.
In any event, security is getting interesting again. Do we now work in a discipline which, rather than being a perceived cost and burden to an organisation, could quickly become a competitive differentiator? I can see it happening, but not while spending patterns are so ‘feast or famine ‘? Maybe it’s time to start bidding for security funding not just for compliance and risk mitigation, but as a way that organisations can improve customer confidence, retention and intimacy through cast-iron security guarantees.
This may sound like blue-sky thinking – particularly in the context of things like Advanced Persistent Threats (APTs). If a syndicate has enough time and resources, won’t they always find a way in? Not if you have the right resources to hand. Whether access to your systems has been socially engineered, or via a stealth APT that may have taken 6 months, a good logging solution is key. Pinpoint and exploit early warnings, and use targeted resources to take remedial action and mobilise defences quickly. Be warned though – feast or famine won’t work – this requires a little effort, often.
Tags: advanced persistent threats, compliance, network security, pci
The Nuances of Advanced Correlation Rules for Authentication Logs
Using the Advanced Intelligence (AI) Engine with LogRhythm allows users to correlate among all the logs in a network and alert when there is anything unusual in the log patterns. My team, the Knowledge Engineers, is tasked with creating rules for advanced correlation and pattern recognition. In the early days of the AI Engine, however, we ran across many unexpected challenges when building many of our prepackaged correlation rules.
Let’s start with an example:
One of our AI Engine rules is designed to detect a brute force attempt followed by a successful login on the same account. First this rule looks to see if there are at least 5 authentication failures followed by a successful logon by that same origin login. Seems simple enough, however in the AI Engine Beta program we discovered that this alert fires way too often.
Why is this? Investigation into this issue showed us that the Windows logon process doesn’t produce logs exactly how we expected (or how we would like). It turns out that if domain controllers in the environment are connected, then an authentication failure log is produced for every domain controller in the system. This means that in a large environment, someone who types their password incorrectly only one time can produce as many authentication failure logs as there are domain controllers in the network running active directory. In this case, this AI Engine rule, which is supposed to catch people logging into accounts that aren’t theirs, had a very high false positive rate during beta testing.
But that raised the question what about other windows authentication events, such as logons, so we decided to investigate further. Testing logons just around our office yielded a wide variety of results. When I logged in I produced 12 logs classified as Authentication Success and even 4 logs that were classified as Logoffs. Another employee produced 49 logs with a single logon! Some of these logon logs are simply connections to shared resources like a network drive – not actual logons. If a typical user of LogRhythm wants to investigate a specific employee, they will want to find the exact time the employee in question logged on, what they accessed, and what that person did with the objects they accessed. This is a daunting task for a user that doesn’t have a deep understanding of Windows authentication events.
With the creation of the AI Engine rules we realized just how noisy authentication events actually are in Windows. To address this issue, we have fine-tuned our common events and AI Engine rules to filter out all of this extra noise. Because AI Engine rules can leverage all of LogRhythm’s extensive normalization, data enrichment and log parsing, they can be quickly modified for much greater accuracy. And a typical LogRhythm user can investigate incidents without having to understand every individual detail of the Windows authentication process. That is what every SIEM product user is looking for – a simple way to understand exactly what is happening in their network without needing a detailed knowledge of the authentication process.
Not only did this analysis help us create more refined AI Engine rules with fewer false positives, it gave us more refined guidance for normalization, making LogRhythm easier for our customers to use.
Tags: advanced correlation, brute force attack, logrhythm, network security
LizaMoon : Analysis of a Blended Attack
There is a great write up on the LizaMoon attack on the SpiderLabs® Anterior blog. In this breakdown we’re shown multiple examples of the SQL injection payloads used by the attackers. What makes this particular attack interesting however are not the SQL payloads, but what the strings are being used to attack.
The first target of this blended attack are custom web applications. Ryan Barnett with SpiderLabs describes the challenges associated with mass attacking such a target below.
Historically, criminals had a tough time creating SQL Injection payloads that would mass exploit web applications. This was mainly due to websites running custom coded apps. No two sites were the same. This means that attackers didn’t have access to the target code so they were forced to conduct manual reconnaissance probes to enumerate database structures. This meant that if an attacker wanted to extract out customer credit card data from a back-end database, they would be forced to run reconnaissance probes in order to enumerate the database structure and naming conventions. This manual probing offered defenders time to identify and react to attacks before successful compromise of customer data.
So how did the Lizamoon attackers pull this off? The article appropriately sheds light on this key component of the attack but doesn’t elaborate in detail on the process. Without web server and/or database logs it’s difficult to know exactly what methods they employed. While I have seen reports of the XSS code being mass inserted into all DB fields, it seems likely that this actually represents a case where the attack is malfunctioning. Scanning the DB for common field names such as “title” may do the trick in some cases, but would not work all the time.
Regardless of how that first component of the attack is executed, it is clear that other parts of the attack are not as clever and are being misunderstood or simply not identified properly. While multiple sources mark March 29th as the start of this attack, evidence paints a different picture. Take for example 95.64.9.18. Later in the cycle of this attack, the IP resolved to hxxp: //worid-of-books.com and was one of the domains frequently seen being injected. In the attack’s earlier stages however, at least as early as February 11th, this IP was reportedly seen attempting a SQL injection against various servers.
Accurate or not, there seems to be even less information on the payload and its delivery method. Grouping all Rogue Security Applications into the same bucket might keep us from gathering a good understanding of the overall attack, but where are the Rogue Security Applications? I think it’s safe to say that the criminals were probably disappointed by falling so short of what this attack could have been. But, whether you give credit to security researchers for acting quickly to shut down domains or you simply consider it poor planning on the scammers’ part, we can expect to see better randomization and distribution of domain names the next time around.
An interesting byproduct of this attack is the number and variety of URLs pushing pay-per-click ads jumping on the LizaMoon media bandwagon. Like this gem:
Crafty marketing or a simple case of web vigilantism in action?
Tags: lizamoon, network security, rogue security applications, sql injection
Compliance buys the steak, but where is the sizzle?
Another meeting or WebEx demo is scheduled – things are busy for me six months in as Sales Engineer for LogRhythm in the UK. I dial into the conference call and off we go. The first question that normally gets asked by one of my enthusiastic sales colleagues is “what’s the driver for the project…?” To date the answer is usually “compliance“.
I’ve worked with enterprise networks for over 10 years now and was responsible for designing, deploying and managing a large network for a leading Managed Security Services provider. When I designed the network, I paid no attention to log and event management. I knew that each of the products and technologies created logs and had their own management interface to allow me to view that information if needed. From what I’ve seen, this isn’t an uncommon approach. It then happened……
… Friday night @ 17:00hrs, my phone rings and it’s one of the sales managers on the phone: “Hi, can you create a report showing when John Doe has logged into the network over the past two weeks?” Ok, this isn’t too much of a task for me I think, I can simply log into the domain controller and take a look at the security logs, export the information to excel, manually edit it and create a report. Then the same sales manager asks “I also want to know what websites John Doe has visited whilst logged into the corporate network. Oh, and can you tell me if they have also logged in remotely over the VPN? If I can have the reports on my desk Monday morning, that would be good.” All of a sudden the fairly simple task becomes more complicated and will require the use of various different GUIs, tools and lots of my weekend!
…Back to the demo: As I walk through the console showing the customer how easy it is to run an investigation against any or all of the log sources, showing how to use the common events and classifications to apply filters (Origin Login = John Doe, Classification = Authentication Success) to the log data that LogRhythm has enriched and normalized, I then show how easy it is to use the displayed data

and create a graphical report.
I continue to demonstrate the power of tail in a troubleshooting or activity monitoring scenario and apply a filter showing URL and Origin Login = John Doe and we sit there in real-time watching the user’s activity. It’s about this point that the pin drops.

Yes the driver might be Compliance, but it’s the additional operational features and visibility that LogRhythm provides that gets the technical operations team excited and actually sells the product more often that compliance on its own.
I wish I had paid more attention to my SIEM requirements when I designed the MSSP network all those years back. If I had I would have made it home much earlier that Friday night!
Tags: compliance, log management, network security, siem
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."