Category Archives: incident response

High-Level FAQ for Incident Response

Posted on by
Reply

  1. Q: What is an incident response process in information security?

A: The incident response process in information security is a systematic approach to identifying, containing, analyzing, and resolving security incidents that may compromise the confidentiality, integrity, or availability of an organization’s information systems and data. It involves a set of predefined policies, procedures, and tools designed to minimize the impact of security incidents and facilitate a swift recovery.

  1. Q: Why is the incident response process necessary?

A: The incident response process is crucial for organizations because it helps to minimize the damage caused by security incidents, protect sensitive data, maintain business continuity, and comply with regulatory requirements. A well-defined incident response process can also help organizations learn from security incidents and improve their overall security posture.

  1. Q: What are the critical phases of an incident response process?

A: The incident response process typically includes six key phases:

  • i. Preparation: Developing and maintaining an incident response plan, training staff, and setting up necessary tools and resources.
  • ii. Detection and Analysis: Identifying potential security incidents through monitoring, reporting, and analyzing security events.
  • iii. Containment: Limiting the spread and impact of an identified security incident by isolating affected systems or networks.
  • iv. Eradication: Removing the cause of the security incident, such as malware or unauthorized access, and restoring affected systems to a secure state.
  • v. Recovery: Restoring affected systems and networks to regular operation and verifying their security.
  • vi. Post-Incident Activity: Reviewing the incident response process, identifying lessons learned, and implementing improvements to prevent future incidents.

  1. Q: Who should be involved in the incident response process?

A: An effective incident response process involves a cross-functional team, typically called the Incident Response Team (IRT), which may include members from IT, information security, legal, human resources, public relations, and management. External stakeholders, such as law enforcement, third-party vendors, or cyber insurance providers, may also be involved, depending on the nature and severity of the incident.

  1. Q: How can organizations prepare for incident response?

A: Organizations can prepare for incident response by:

  • Developing a comprehensive incident response plan that outlines roles, responsibilities, and procedures for each process phase.
  • Regularly updating and testing the incident response plan to ensure its effectiveness and relevance.
  • Training employees on their roles and responsibilities during an incident, including reporting procedures and essential security awareness.
  • Establishing a well-equipped IRT with clear communication channels and access to necessary resources.
  • Implementing continuous monitoring and detection tools to identify potential security incidents early.

  1. Q: How can organizations improve their incident response process?

A: Organizations can improve their incident response process by:

  • Regularly reviewing and updating the incident response plan to reflect changes in the organization’s infrastructure, personnel, and threat landscape.
  • Conducting periodic tests and simulations, such as tabletop exercises or red team exercises, to evaluate the plan’s effectiveness and identify improvement areas.
  • Implement a continuous improvement cycle incorporating lessons learned from past incidents and industry best practices.
  • Investing in advanced detection and monitoring tools to enhance the organization’s ability to identify and respond to security incidents.
  • Providing ongoing training and support to the IRT and other stakeholders to ensure they remain up-to-date with the latest threats and best practices.

 

*This article was written with the help of AI tools and Grammarly.

Best Practices for DHCP Logging

Posted on by
Reply

As an IT and security auditor, I have seen the importance of DHCP logging in, ensuring network security, and troubleshooting network issues. Here are the best practices for DHCP logging that every organization should follow:

 

1. Enable DHCP Logging: DHCP logging should be turned on to record every event that occurs in the DHCP server. The logs should include information such as the time of the event, the IP address assigned, and the client’s MAC address.

2. Store DHCP Logs Securely: DHCP logs are sensitive information that should be stored in a secure location. Access to the logs should be restricted to authorized personnel only.

3. Use a Centralized Logging Solution: To manage DHCP logs, organizations should use a centralized logging solution that can handle logs from multiple DHCP servers. This makes monitoring logs, analyzing data, and detecting potential security threats easier.

4. Regularly Review DHCP Logs: Regularly reviewing DHCP logs can help detect and prevent unauthorized activities on the network. IT and security auditors should review logs to identify suspicious behavior, such as unauthorized IP and MAC addresses.

5. Analyze DHCP Logs for Network Performance Issues: DHCP logs can also help identify network performance issues. By reviewing logs, IT teams can identify IP address conflicts, subnet mask issues, and other network performance problems.

6. Monitor DHCP Lease Expiration: DHCP lease expiration is vital to ensure IP addresses are not allotted to unauthorized devices. DHCP logs can help to monitor lease expiration and to deactivate the leases of non-authorized devices.

7. Implement Alerting: IT and security audit teams should implement alerting options to ensure network security. By setting up alert mechanisms, they can be notified of suspicious activities such as unauthorized devices connecting to the network or DHCP problems.

8. Maintain DHCP Logs Retention Policy: An effective DHCP logs retention policy should be defined to ensure logs are saved for an appropriate period. This policy will help to provide historical audit trails and to comply with data protection laws.

 

Following these DHCP logging best practices will help ensure the network’s security and stability while simplifying the troubleshooting of any network issues.

Saved By Ransomware Presentation Now Available

Posted on by
Reply

I recently spoke at ISSA Charlotte, and had a great crowd via Zoom. 

Here is the presentation deck and MP3 of the event. In it, I shared a story about an incident I worked around the start of Covid, where a client was literally saved from significant data breach and lateral spread from a simple compromise. What saved them, you might ask? Ransomware. 

That’s right. In this case, ransomware rescued the customer organization from significant damage and a potential loss of human life. 

Check out the story. I think you’ll find it very interesting. 

Let me know if you have questions – hit me up the social networks as @lbhuston.

Thanks for reading and listening! 

Deck: https://media.microsolved.com/SavedByRansomware.pdf

MP3: https://media.microsolved.com/SavedByRansomware.mp3

PS – I miss telling you folks stories, in person, so I hope you enjoy this virtual format as much as I did creating it! 

Utility Tabletop Cybersecurity Exercises

Posted on by
Reply

Recently, a group of federal partners, comprised of the Federal Energy Regulatory Commission (FERC), North American Reliability Corporation (NERC) and it’s regional entities released their Cyber Planning for Response and Recovery Study (CYPRES). The report was based on a review and analysis of the incident response and recovery capabilities of a set of their member’s cyber security units, and is a great example of some of the information sharing that is increasing in the industry. The report included reviews of eight utility companies’ incident response plans for critical infrastructure environments, and the programs reviewed varied in their size, complexity and maturity, though all were public utilities.

Though the specific tactics suggested in the report’s findings have come under fire and criticism, a few items emerged that were of broad agreement. The first is that most successful programs are based on NIST 800-61, which is a fantastic framework for incident response plans. Secondly, the report discusses how useful tabletop exercises are for practicing responses to cybersecurity threats and re-enforcing the lessons learned feedback loop to improve capabilities. As a result, each public utility should strongly consider implementing periodic tabletop exercises as a part of their cyber security and risk management programs.

Tabletop Exercises from MSI

At MicroSolved, we have been running cyber security tabletop exercises for our clients for more than a decade. We have a proprietary methodology for building out the role playing scenarios and using real-world threat intelligence and results from the client’s vulnerability management tools in the simulation. Our scenarios are developed into simulation modules, pre-approved by the client, and also include a variety of randomized events and nuances to more precisely simulate real life. During the tabletop exercise, we also leverage a custom written gaming management system to handle all event details, track game time and handle the randomization nuances.

Our tabletop exercise process is performed by two MSI team members. The first acts as the simulation moderator and “game master”, presenting the scenarios and tracking the various open threads as the simulation progresses. The second team member is an “observer” and they are skilled risk management team members who pre-review your incident response policies, procedures and documentation so that they can then prepare a gap analysis after the simulation. The gap analysis compares your performance during the game to the process and procedure requirements described and notes any differences, weaknesses or suggestions for improvement.

Target scenarios can be created to test any division of the organization, wide scale attacks or deeply nuanced compromises of specific lines of business. Various utility systems can be impacted in the simulation, including business networks, payment processing, EDI/supply chain, metering/AMI/smart grid, ICS/SCADA or other mission critical systems.Combination and cascading failures, disaster recovery and business continuity can also be modeled. In short, just about any cyber risks can be a part of the exercise.

Tabletop Exercise Outcomes and Deliverables

Our tabletop exercises result in a variety of detailed reports and a knowledge transfer session, if desired. The reports include the results of the policy/procedure review and gap analysis, a description of the simulated incident and an action plan for future improvements. If desired, a board level executive summary can also be included, suitable for presentation to boards, management teams, direct oversight groups, Public Utility Commission and Homeland Security auditors as well.

These reports will discuss the security measures tested, and provide advice on proactive controls that can be implemented, enhanced, matured or practiced in order to display capabilities in future incidents that reflect the ability to perform more rapid and efficient recovery.

The knowledge transfer session is your team’s chance to ask questions about the process, learn more about the gaps observed in their performance and discuss the lessons learned, suggestions and controls that call for improvement. Of course the session can include discussions of related initiatives and provide for contact information exchange with our team members, in the event that they can assist your team in the future. The knowledge transfer session can also be performed after your team has a chance to perform a major review of the reports and findings.

How to Get Started on Tabletop Exercises from MSI

Tabletop exercises are available from our team for cyber security incidents, disaster preparedness and response or business continuity functions. Exercises are available on an ad-hoc, 1 year, 2 year or 3 year subscription packages with frequencies ranging from quarterly to twice per year or yearly. Our team’s experience is applicable to all utility cyber programs and can include any required government partners, government agencies or regulators as appropriate.

Our team can help develop the scope of threats, cyber attacks or emergency events to be simulated. Common current examples include ransomware, phishing-based account compromises, cyber attacks that coincide with catastrophic events or service disruptions, physical attacks against substations or natural gas pipelines, data breach and compromise of various parts of the ICS/SCADA infrastructure. Our team will work with you to ensure that the scenario meets all of your important points and concerns.

Once the scenario is approved, we will schedule the simulation (which can be easily performed via web-conference to reduce travel costs and facilitate easy team attendance) and build the nuances to create the effects of a real event. Once completed, the reporting and knowledge transfer sessions can follow each instance.

Tabletop exercises can go a long way to increasing cybersecurity preparedness and re-enforcing the cybersecurity mindset of your team. It can also be a great opportunity for increasing IT/OT cooperation and strengthening relationships between those team members.

To get started, simply contact us via this web form or give us a call at (614) 351-1237. We would love to discuss tabletop exercises with you and help you leverage them to increase your security posture.

 

Detecting Info Leaks with ClawBack

Posted on by
Reply

Clawback smallClawBack Is Purpose Built to Detect Info Leaks

ClawBack is MicroSolved’s cloud-based SaaS solution for performing info leak detection. We built the tool because we worked so many incidents and breaches related to three common types of info leaks:

  • Leaked Credentials – this is so common that it lies at the root of thousands of incidents over the last several years, attackers harvest stolen and leaked logins and passwords and use them anywhere they think they can gain access – this is so common, it is even categorized by OWASP as a specific form of attack: credential stuffing 
  • Leaked Configurations – attackers love to comb through leaked device and application configuration files for credentials, of course, but also for details about the network or app environment, sensitive data locations, cryptographic secrets and network management information they can use to gain control or access
  • Leaked Code – leaked source code is a huge boon for attackers; often leaking sensitive intellectual property that they can sell on the dark web to your competitors or parse for vulnerabilities in your environment or products

MicroSolved knows how damaging these info leaks can be to organizations, no matter the type. That’s exactly why we built ClawBack to provide ongoing monitoring for the info leak terms that matter most to you.

How to Get Started Detecting Info Leaks

Putting ClawBack to work for you is incredibly easy. Most customers are up and monitoring for info leaks within 5 minutes.

There is no hardware, software, appliance or agent to deploy. The browser-based interface is simple to use, yet flexible enough to meet the challenges of the modern web. 

First, get a feel for some terms that you would like to monitor that are unique to your organization. Good examples might be unique user names, application names, server names, internal code libraries, IP address ranges, SNMP community strings, the first few hex characters of certificates or encryption keys, etc. Anything that is unique to your organization or at the very least, uncommon. 

Next, register for a ClawBack account by clicking here.

Once your account is created, and you follow the steps to validate it, you can login to the ClawBack application. Here, you will be able to choose the level of subscription that you would like, picking from the three different service levels available. You will also be able to input your payment information and set up additional team members to use the application, if available at your subscription level. 

Next, click on Monitoring Terms and input the terms that you identified in the first step. ClawBack will immediately go and search for any info leaks related to your terms as you put them in. Additionally, ClawBack will continually monitor for the terms going forward and provide alerts for any info leaks that appear in the common locations around the web. 

How To View Any Info Leaks

Reviewing any info leaks found is easy, as well. Simply click on Alerts on the top menu. Here, your alerts will be displayed, in a sortable list. The list contains a summary of each identified leak, the term it matched and the location of the leak. You can click on the alert to view the identified page. Once reviewed, you can archive the alert, where it will remain in the system and is visible in your archive, or you can mark it as a false positive, and it will be removed from your dataset but ClawBack will remember the leak and won’t alert you again for that specific URL. 

If you have access to the export function, based on your subscription level, you can also so export alerts to a CSV file for uploading into SIEM/SOAR tools or ticketing systems. It’s that easy! 

You can find a more specific walkthrough for finding code leaks here, along with some screen shots of the product in action.

You can learn more about ClawBack and view some use case videos and demo videos at the ClawBack homepage.

Give ClawBack a try today and you can put your worries to rest that unknown info leaks might be out there doing damage to your organization. It’s so easy, so affordable and so powerful that it makes worries about info leaks obsolete.

Prepping for Incident Response

Posted on by

Prepping? Who wants to prep for incident response?

This particular bit of writing came from a question that I was asked during a speaking engagement recently – paraphrased a bit.

How can a client help the incident team when they’re investigating an incident, or even suspicious activity? 

So, I circulated this to the team, and we tossed around some ideas.

Continue reading →

BEC #6 – Recovery

Posted on by

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Discover. Part 3 covered the next checkpoint – Protect. Part 4 continued the series – Detect. Part 5 addressed how to Respond.

Continue reading →

How do you “identify”…BEC #2

Posted on by

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Continue reading →

Enter the game master….disaster recovery tabletops!

Posted on by

I snagged this line from the most excellent Lesley Carhart the other day, and it’s been resonating every since.

“You put your important stuff in a fire safe, have fire drills, maintain fire insurance, and install smoke detectors even though your building doesn’t burn down every year.”

When’s the last time you got out your business continuity/disaster recovery plan, dusted it off, and actually READ it? You have one, so you can check that compliance box…but is it a living document?

It should be.

All of the box checking in the world isn’t going to help you if Step #2 of the plan says to notify Fred in Operations…and Fred retired in 2011. Step #3 is to contact Jason in Physical Security to discuss placement of security resources…and Jason has changed his cell phone number three times since your document was written.

I’ve also seen a disaster recovery plan, fairly recently, that discussed the retrieval and handling of some backup….floppy disks. That’s current and up-do-date?

Now, I am an active tabletop gamer. Once a week I get together with like-minded people to roll the dice and play various board games.

For checking the validity of your disaster recovery plan there is an excellent analog to the tabletop gaming world:

Tabletop DR exercises!

Get BACK here….I see you in the third row, trying to sneak out. I’ll admit, I LOVE doing tabletops. Hello? I get to play game master, throw in all kinds of random real life events, and help people in the process – that’s the trifecta of awesome, right there. If it’s a really good day, I get to use dice, as well!

The bare minimum requirements for an effective tabletop:

  • A copy of  your most recent DR/BC plan
  • Your staff – preferably cooperative. Buy ’em a pizza or three, will you? The good kind. Not the cheap ones.
  • An observer. This person’s job is to review your plan in advance, and observe the tabletop exercise while taking notes. They will note WHAT happens, and what actions your team takes during the exercise. This role is silent, but detail oriented.
  • And the game master. The game master will present the scenario to the team. They will interact with the team during the exercise, and will also be the one who generates the random events that may throw the plan off track. It’s always shocking to me how many people would rather be the observer….to me, game master is where the fun is.

Your scenario, and the random event happenings, should fit your business. I tend to collect these for fun….and class them accordingly. A random happening where all credit card processing is doubling due to an error in the point of sale process is perfect for a retail establishment…but an attorney’s office is going to look at me like I have three heads.

Once the exercise is over, the game master and observer should go over all notes, and generate a report. What did the team do well, what fell off track, what updates does the plan need, and what is missing from the plan entirely?

Get the team together again. Buy ’em donuts – again, the good ones. Good coffee. Or lunch. Never underestimate the power of decent food on technical resources.

Try to start on a high note, and end on a high note. Make plans, as you review – what are the action items, and who owns them? When and how will the updates be done? When will you reconvene to review the updates and make sure they’re clear and correct?

Do this, do it regularly, and do NOT punish for the outcome. It’s an exercise in improvement, always…not something that your staff should dread.

Have a great DR exercise story? Have a REALLY great random event for my collection? I’d love to hear it – reach out. I’m on Twitter @TheTokenFemale, or lwallace@microsolved.com

Worm detection with HoneyPoint Security Server (HPSS): A real world example

Posted on by
Reply

This post describes a malware detection event that I actually experienced a few short years ago.

My company (Company B) had been acquired by a much larger organization (Company A) with a very large internal employee desktop-space. A desktop-space larger than national boundaries.

We had all migrated to Company A  laptops – but our legacy responsibilities required us to maintain systems in the original IP-space of company B.  We used legacy Company B VPN for that.

I had installed the HPSS honeypoint agent on my Company A laptop prior to our migration into their large desktop space.  After migration I was routinely VPN’ed into legacy Company B space, so a regular pathway for alerts to reach the console existed.

After a few months, the events shown in the diagram below occurred.

I started to receive email alerts directed to my Company B legacy email account. The alerts described TCP 1433 scans that my Company A laptop was receiving.  The alerts were all being thrown by the MSSQL (TCP 1433 – Microsoft SQL Server) HoneyPoint listener on my laptop.

I was confused – partly because I had become absorbed in post-acquisition activities and had largely forgotten about the HPSS agent running on my laptop.

After looking at the emails and realizing what was happening, I got on the HPSS console and used the HPSS event viewer to get details. I learned that the attackers were internal within Company A space. Courtesy of HPSS I had their source IP addresses and the common payload they all delivered.  Within Company A I gathered information via netbios scans of the source IPs.  The infected machines were all Company A laptops belonging to various non-technical staff on the East Coast of the U.S.

All of that got passed on to the Company A CIO office. IDS signatures were generated, tweaked, and eventually the alerts stopped.  I provided payload and IP information from HPSS throughout the process.

I came away from the experience with a firm belief that company laptops, outfitted with HoneyPoint agents, are an excellent way of getting meaningful detection out into the field.

I strongly recommend you consider something similar. Your organization’s company laptops are unavoidably on the front-line of modern attacks.

Use them to your advantage.