Wannacry and NotPetya are just the beginning - Can you detect lateral movement from Event Logs - Yes but how?

Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) has a excellent document 


Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) extracted tools used by many attackers by investigating recently confirmed cases of targeted attacks. Then, a research was conducted to investigate what kind of logs were left on the server and clients by using such tools, and what settings need to be configured to obtain logs that contain sufficient evidential information. This report is a summary of the results of this research

The following Page has a PDF link 

https://www.jpcert.or.jp/english/pub/sr/ir_research.html

If You Are Doing Incident Response, You Are Doing It Wrong

Short but an excellent article that emphasizes on Incident Management 

According to the article:-

By managing incidents rather than responding to them, you:

• Reduce the severity of the incidents that do occur.
• Reduce the number of incidents that do occur.
• Shift from responding to incidents to managing incidents as part of your normal operations
• Reduce unforeseen expenses related to incident investigations
• Increase your visibility within the business, and thus the support for your organization
• Strengthen security posture (Thank you to Corey)
• Reduce stress on your staff and increase their job satisfaction (unless they are adrenalin junkies)

An incident management mindset depends on accepting a truism:

Compromise Is Inevitable – Something truly malicious has been in, is in, and will be in your environment.

The link below has more information:-

http://integriography.wordpress.com/2014/05/06/if-you-are-doing-incident-response-you-are-doing-it-wrong/

IR (Incident Response) - A few good thoughts

Nice thoughts and a few good comments

From the Article:

• First, prevention and preventative security controls will fail. Prevention fails on a daily basis at many organizations; it will suffice to look at antivirus tools and contrast their 99%-plus deployment rates with widespread ongoing malware infection rates."
• "Second, detection also fails on a frequent basis. A copy of Verizon Data Breach Investigations Report reveals plentiful evidence of that."
• "What remains of the entire realm of information security. Only incident response."

"Thus, IR simply has to be there because this is where the security of an organization will fall after all else fails - and it will."

The link below has more information:

http://journeyintoir.blogspot.com/2014/04/holding-line.html

SOC Analyst - How not to miss alerts (and get blamed)

Normally, you find a lot of unwanted information related to SOC, this article provides some nice advice without all the fluff.

According to the article:-

1. Since many SOC analysts are new to this field, add documentation to signatures so they can fully understand their context and can more easily identify when they should ask for help.
2. Tune out noisy alerts by providing a mechanism for analysts to easily flag them in the course of their daily duties and setting up a regular meeting to review submitted alerts.
3. Let analysts focus on their job of analyzing alerts and not side tasks outside of their normal daily responsibilities.
4. Keep analysts in the know of any incident response activities so they can better understand signature context (even if they weren’t directly involved) and gain a perspective beyond just the alert queue.
5. Motivate analysts by giving them training that enhances their abilities in their current job and prepares them for their next one, offering small challenges to test their skills, and recognizing their successes.

The link below has more information:-

http://blog.handlerdiaries.com/?p=552

Incident Reporting - Measuring the right stuff

The author makes some good points that people tend to ignore

According to the article:- 

Instead of starting with preconceived notions of what is or what should be, focus on:

1. Connecting people to value: their own, as well as the value of others, the business, and how security helps protect what's important
2. Context: finding a shared understanding of the current culture
3. Conversation: listening and learning before telling, building relationships that guide and improve the overall cultural evolution

For metrics to be successful, they need to be:

1. Accessible
2. Actionable
3. Auditable

The link below has more information:-

http://www.csoonline.com/article/2139405/security-leadership/why-you-need-to-measure-the-right-things-in-your-incident-reporting-process-to.html

Incident Response - 7 Tips on what you could do when you have an Incident

Here, the author refers to the Buffer site hack but, offers a few tips on incident response


According to the article:- 

For most incidents, the initial response should be some flavor of the following steps:

1. Understand, as quickly as possible, that you have an incident, and communicate this to internal and external shareholders. Obviously the decision about exactly who are the stakeholders is highly variable, depending on an incredibly long list of considerations – I wouldn't recommend everyone go public – in many cases that is exactly what not to do. But if the cat is out of the bag (that is, say, if a half-million of your customers are now advertising diet pills in their social media timelines), this decision may have been made for you.
2. Understand, as quickly as possible, the initial scope of the incident (much of what you learn and assume in these early hours will be wrong, but you should work hard to get the most complete sense of what is happening and what systems are affected — you'll be coming back to this step repeatedly).
3. Once you have a scope, devise a plan to, in this order, stop the bleeding, secure what you have, and re-assess the scope and breadth of the incident.
4. Develop an understanding of your available resources as mapped to the plan you've just made, determine the Deltas between what you have and what you need. This requires a brutally honest self-assessment, and almost certainly must be something you've considered in advance; you can develop this awareness after the fact, but you're increasing exponentially the cost of the incident response — put another way, every dollar you spend doing this work in advance is worth $5 when the defecation hits the ventilation.
5. Work with partners to fill the gaps between what you have and what you need. Rapidly.
6. Repeat the last four steps until you feel you have positive control.
7. Continue to communicate what you know, when you know it, to appropriate and appropriately growing groups of stakeholders. Don't make promises you can't keep or statements not based on fact, but don't shut up until you have facts if stakeholders are visibly or audibly nervous. "We have had a security incident that we understand has affected ____________, and with our staff and partners we are working quickly to determine the extent of the damage and we will report back regularly with progress," is much better than not saying anything and allowing speculation to fester.

The link below has more information:-

http://www.csoonline.com/article/2134108/emergency-preparedness/incident-response-matters.html

Incident Response - 5 Useful Tips

Organizations spend money on Prevention and Detection but most fail in IR.

So, IR has always been one of my favorite topics.

According to the article:- 

TIPS:

1. Know your target data
2. Document plans for various scenarios
3. Establish a base of operations
4. Nominate a single point of contact
5. Update and maintain

Incident response is something that is developed and something that changes with the organization over time.

"So they spend all this time, and all this training, and all this education that they've got, and all the money that they invested in parameter defense, and even internal defenses, but they didn't spend a dime on incident response.

Incident response tends to be, in most cases, an ad-hoc thing that's put together as needed; it's almost like a volunteer fire department. The only difference is that the volunteer fire department is properly trained, they have the right processes, [and] they have the right tools."

Unless plans were developed and tested beforehand, then these common problems show themselves at the worst possible time; during an actual incident.

"What IT gets right is that they know their infrastructure. They know where their data of value is, they know ingress points [and] they know egress points. It's their network, they understand how it works. What they get wrong is they don't use the working knowledge that they have of the network to understand how and incident would occur," 

One of the often repeated problems with incident response is that organizations rarely understand those who are attacking them, what the attacker is looking for, and how they are trying to get it.

Knowing all the routes and access points to the critical data is a must, so that when something happens you can accurately flag the incident and deal with it appropriately.

No matter how good the plan is, it never survives its first real test. Make sure there is an after action report made, and that any mistakes, problems, or failures are learned from. Adjust plans and policies as needed

The link below has more information:-

http://www.csoonline.com/article/2133834/business-continuity/understanding-incident-response-5-tips-to-make-ir-work-for-you.html

Neiman Marcus and Target - Both missed the alerts/alarms. why?

This article is similar to my previous post but the author asks a few relevant questions.

In the article:- 

Some questions to consider when evaluating tools used in incident response include:

• Do you have a way, when an event fires, to get more context in order to determine whether or not that event is real and deserves further investigation?

• How expensive is it to obtain that context? Do you have to go out and look at the potentially infected computer, or do you have telemetry flowing back from that computer into a system that is accessible to the SOC that they can investigate?

• If you have telemetry, what kind? Is it system-level telemetry that can be manipulated post breach, or is it network-level telemetry that is hard to manipulate?

• How close to the source are you collecting telemetry – are you capturing everything that infected host is doing or just its communications out to the Internet?

The links below has more information:

http://www.lancope.com/blog/when-an-alarm-isnt

Free Tool: CrowdResponse - For Incident Response amd Malware research

SNIPPETS from the Article:-

CrowdResponse is a modular Windows console application designed to aid in the gathering of host information for incident response engagements.

This initial version provides three useful built-in modules

1. @dirlist - This is the directory-listing module. This sounds quite simple, but it is actually extremely powerful.
2. @pslist - This is the active running process listing module.
3. @yara - YARA will be familiar to many as an incredibly useful tool aimed at helping malware researchers identify and classify malware. It can act on files on disk or in-memory process images and runs a set of pattern matching rules against the target of investigation.

The links below has more information:

http://www.crowdstrike.com/blog/new-community-tool-crowdresponse/index.html