With the war being waged in Ukraine and other global unrest, your company could be a possible target of hackers looking to infiltrate your IT systems and uncover vital intelligence about your work with the DoD, your technology, your contracts, and more. What can you do to be alerted to any incursions into your infrastructure–and how can you stay ahead of the threats and guard against incidents?
Know what constitutes an cyber incident
These occurrences are centered around network or system breaches. With the post-COVID work environment resulting in a lot of remote workers, there can be many ways to infiltrate your systems.
At the most basic level, incidents are some type of intrusion for the purpose of political espionage or to acquire trade secrets. Typically for the defense industry base that translates to an attack against cloud infrastructure via an insertion of malicious software. An incident could also be a physical breach, such as a car break-in resulting in company laptop theft.
How do you know that a cyber incident has happened?
Receiving notification that an incident has occurred is the first step to mitigating its impact. Make sure you have deep visibility into your IT infrastructure, which could include laptops, cloud infrastructure, and more. Reviewing logs from the multiple security products that monitor these disparate systems provides insight into vulnerabilities and abnormalities in your environment. The team at CyberSheath is skilled at this review and analysis.
For example, Azure Active Directory through Microsoft allows us to geolocate where an employee is attempting to log in. Analytic alerts may notify us of an employee who is based in San Diego trying to access your systems from Calgary, which could signal an issue of compromised credentials. We can also see when someone successfully is able to log in through the first factor, which is the password, but then fails multifactor authentication, which also indicates a potential issue. These are indications of a breach in progress, and then, depending on the security proxy in place, we can investigate and escalate to your company as necessary.
Reporting cyber incidents
DFARS requires that you report a cybersecurity incident within 72 hours. Any malicious software has to be provided to the DoD cybercrime center. Using our tools, we can isolate a host and download the potentially malicious file. Learn how to report these incidents to the DoD–and if you are a subcontractor, be sure to also inform your prime.
Threat levels and category definitions
- Critical – These rare occurrences represent a real or imminent threat that would severely impact overall business availability, including widespread ransomware or breaches that result in down email. Unauthorized access changes, unauthorized release or disclosure of information, network intrusion, or widespread malicious incidents are often at the root of these issues. If you have good security hygiene and the products required, incidents don’t become critical. It’s typically companies with no patch management or endpoint detection response system that have these urgently important incidents.
- High – These incidents hold moderate impact. It could be that an entity is scanning your network and you need to jump on it right away. They indicate an internal threat, perhaps where someone changes a password or there’s privilege abuse, and a malicious code is launched.
- Medium – Not posing an immediate threat, these occurrences are time-sensitive and suspicious–and could have a long term business risk. This could be an employee’s email account getting compromised. In this example, a threat actor could then use this internal account to gain more access to internal systems and information.
- Low – These happenings are typically related to non-standard client content configurations and potential improper use. Perhaps someone visits a website that may be suspect, or uses a VPN. These things can obviously get escalated up the chain for verification, but there may be justifiable business uses that still trigger an alert.
A note about false positives
In monitoring incidents, it is always better to investigate issues that ultimately turn out to not be threats, than to have potentially harmful activities go unnoticed. Some client environments may have an initial false positive rate of up to 70% before tuning. Typically these false positive events are us flagging someone logging in from a different location. A quick call can then uncover that the employee in question is indeed on the road–and the issue is resolved.
How CyberSheath can help
We offer a variety of services to ensure that your systems are robust and monitored 24/7/365.
- Patch management – Making sure your systems are up to date with the latest patches from all if your technology solutions providers is vital to your cybersecurity. We ensure your systems are all current, which stops incidents from happening.
- Back-up services – Keeping accurate back-ups of all of your company’s electronics information is essential.
- Security Operations Center (SOC) – Information security shouldn’t take evenings off. Our all-day, everyday security monitoring team, takes on the task of making sure your systems are secure and protected, quickly alerting you of possible incidents.
Learn more about our monitoring services and how we can help you secure your infrastructure.
“Those who do not learn from history are condemned to repeat it.”
Over the years, variations of this famous quote have been spoken by everyone from philosophers to world leaders. The message — that we must learn from our mistakes or continue to repeat them — is also highly relevant to cybersecurity.
Both the National Institute of Standards and Technology (NIST) and the SANS Institute describe the learning phase of incident response as one of the most crucial steps, helping businesses to refine and strengthen both their prevention and response protocols.
However, 42% of businesses fail to review and update their incident response plans on a regular basis. If you find yourself experiencing the same security breaches over and over again, you might be one of them. Here’s why you should actively learn from the experience, and how to go about it.
Lessons Learned Session
A lessons learned session takes place after the resolution of a security incident. It involves taking stock of the incident; getting to the root of how and why it happened; evaluating how well your incident response plan worked to resolve the issue; and identifying improvements that need to be made.
Identifying Areas of Weakness
The most obvious benefit of a lessons learned session is that it helps you to identify gaps in your organizational security practices. Was the lapse due to human error? Systems failure? Inadequate security practices? If you don’t know these problems exist, you can’t take the appropriate action to fix them.
Improving Incident Response
Lessons learned sessions help you to understand not only why the incident occurred, but also how effective your response was. For example, were you able to respond quickly and effectively, or did red tape get in the way? Did your team know exactly what to do, or did they struggle to remember their training? Questions like these will highlight areas that need to be improved for next time.
Recognizing the Positive
Don’t just focus on what went wrong in a lessons learned session; it’s also important to highlight what went well. Taking the time to identify successful elements of your response can help to inform robust future security practices while acknowledging and rewarding positive employee performance will set a standard and incentivize similar behaviors in the future.
Lessons Learned Training
Just as frameworks like NIST 800-171 require you to periodically test your Incident Response processes using activities like tabletop exercises, incorporate your lessons learned sessions into these activities as well. Not only will that lead to improvements in your incident response plan, but it will train your teams in how to do effective lessons learned analysis.
The Lessons Learned Process
According to Lessons learned: taking it to the next level, an incident response paper by Rowe and Sykes, lessons learned sessions are most effective when they follow a well-defined five-step process:
- Identify and collect all comments and recommendations that may be useful for future projects.
- Document all findings and share them with key stakeholders.
- Analyze and organize all documentation for future application.
- Store documentation in a repository that can be accessed by all key stakeholder.
- Retrieve documentation for use on current or future incidents.
This process should be implemented as soon as possible after an incident when the particulars are still fresh in everybody’s minds. In fact, if the incident will take an especially long time to resolve, then beginning the process even sooner might uncover helpful information to support the resolution.
Stakeholders from as many key groups as possible should be present for lessons learned sessions. It’s especially important to have representatives from your IT and executive teams, as the former will be able to implement recommendations and the latter will be able to authorize action and remove bureaucratic obstacles.
We’ve Held a Lessons Learned Session — What Next?
Your lessons learned session will likely turn up numerous security gaps, weaknesses, and other areas that need attention. This is the part that often discourages businesses from lessons learned sessions in the first place — after all, if you go looking for problems to fix, then you must fix them! If you don’t have the time or money to do this, then it’s tempting to skip this step altogether and hope for the best.
With the financial impact of the average data breach running into hundreds of millions, this strategy is only going to cost you more money in the long run. Instead, face the incident head-on and use the lessons learned session as an opportunity to proactively fortify your business against future threats.
Here are some examples of actions you might take to improve your cybersecurity and incident response for next time:
- If you found that the incident occurred because your staff missed the signs of a threat or were unsure how to respond, then you may invest in more comprehensive and/or frequent training.
- If bureaucratic layers slowed down your response, you might meet with the C-suite to request executive delegation in future emergency situations, and enshrine this in your incident response plan.
- If a loophole in one of your systems was exploited, conduct a thorough review of the system to ensure it is fit for purpose and replace if necessary.
Whatever you do, though…
Don’t Let History Repeat Itself
Every incident has a lesson to teach you, but we know that implementing these lessons isn’t always easy. That’s why CyberSheath specializes in providing comprehensive, affordable incident response solutions to businesses like yours. Contact us today to find out how we can help.