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.
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:
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
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.
When it comes to Ransomware, it’s generally a good idea to have some contingency and planning before your organization is faced with a real life issue. Here at MicroSolved we offer tabletop exercises tailored to this growing epidemic in information technology.
What if your organization was affected by the Golden Eye or WannaCry today? How quick would you be able to react? Is someone looking at your router or server log files? Is this person clearly defined? How about separation of duties? Is the person looking over the log files also uncharge of escalating an issue to higher management?
How long would it take for you organization to even know if it was affected? Who would be in-charge of quarantining the systems? Are you doing frequent backups? Would you bet your documents on it? To answer these questions and a whole lot more it would be beneficial to do a table top exercise.
A table top exercise should be implemented on an annual basis to evaluate organizational cyber incident prevention, mitigation, detection and response readiness, resources and strategies form the organizations respective Incident Response Team.
As you approach an incident response there are a few things to keep in mind:
An active threat intelligence will help your organization to Analyze, Organize and refine information about potential attacks that could threaten the organization as a whole.
After you gain Threat Intelligence, then there needs to be a contingency plan in place for what to do incase of an incident. Because threats are constantly changing this document shouldn’t be concrete, but more a living document, that can change with active threats.
The IT personal that are in place for Detection and Alerting should be clearly defined in this contingency plan. What is your organizations policy and procedure for frequency that the IT pro’s look at log files, network traffic for any kind of intrusion?
When an intrusion is identified, who is responsible for responding? This response team should be different then the team that is in charge of “Detection and Alerting”. Your organization should make a clearly outlined plan that handles response. The worse thing is finding out you don’t do frequent backups of your data, when you need those backups!
After the incident is over, how are you going to gain the trust of your customers? How would they know there data was safe/ is safe? There should be a clearly defined policy that would help to mitigate any doubt to your consumers.
What went wrong? Murphy’s law states that when something can go wrong it will. What was the major obstacles? How can this be prevented in the future? This would be a great time to take lessons learned and place them into the contingency plan for future. The best way to lesson the impact of Murphy, is to figure out you have an issue on a table top exercise, then in a real life emergency!
This post was written by Jeffrey McClure.
Recently, during one of our TigerTrax™Targeted Threat Intelligence engagements, we were performing passive threat assessments for a popular consumer brand. In the engagement, we not only gathered targeted threat intelligence about their IT environments, applications and hosting partners, but also around the use of their brand on a global scale. The client had selected to take advantage of our dark net intelligence capabilities as well, and were keenly interested in how the dark net, deep web and underground portions of the Internet were engaged with their brand. This is a pretty common type of engagement for us, and we often find a wide variety of security, operational and reputational issues.
This particular time around, we ran into a rather interesting and new concern, at least on the dark net. In this case, a dark net pornography site was using the consumer brand embedded as an HTML comment in the porn site’s main pages. Overall, there were several hundred name brands in the comments. This seems to have been performed so that the search engines that index the site on the dark net, associate the site with the brands. That means when a user searches for the brand name, they get the porn site returned as being associated. In this case, it was actually the first link on several of the dark net search sites we tested. The porn site appears to be using the brand names to lure eyeballs to the site – essentially to up the chance of finding a subscriber base for their particularly nasty set of pornography offerings. Search engine poisoning has been an issue on the public web for some time, and it is a commonly understood tactic to try and link your content to brands, basically serving as “click bait” for users. However, on the dark net, this was the first time we had observed this tactic being used so overtly.
The brand owner was, of course, concerned about this illicit use of their brand. However, there is little they could do to respond, other than reporting the site to the authorities. Instead, after discussing various options, we worked with them to identify an action and response plan for how they would handle the problem if it became a public concern. We also worked with them to identify a standard process that they could follow to bring their existing legal, marketing, management and other parts of their incident response team up to date on threats like these as they emerged.
The client was very pleased to have the discussion and with the findings we identified. While any misuse of their brand is a concern, having their brand associated with pornography or other illicit material is certainly unnerving. In the end, there is little that organizations can do, other than work with authorities or work on take down efforts if the brand is misused on the public web. However, having the knowledge that the issue is out there, and working to develop the threat into existing response plans certainly goes a long way to help them minimize these kinds of risks.
To learn more about dark net brand issues, targeted threat intelligence or passive assessments, drop us a line (info@microsolved dot com) or get in touch on Twitter (@lbhuston) for a discussion.
Today, I ran across this article, and I found it interesting that many folks are discussing how “white hat hackers” could go about helping people by disclosing vulnerabilities before bad things happen.
There are so many things wrong with this idea, I will just riff on a few here, but I am sure you have your own list….
First off, the idea of a corp of benevolent hackers combing the web for leaks and vulnerabilities is mostly fiction. It’s impractical in terms of scale, scope and legality at best. All 3 of those issues are immediate faults.
But, let’s assume that we have a group of folks doing that. They face a significant issue – what do they do when they discover a leak or vulnerability? For DECADES, the security and hacking communities have been debating and riffing on disclosure mechanisms and notifications. There remains NO SINGLE UNIFIED MECHANISM for this. For example, let’s say you find a vulnerability in a US retail web site. You can try to report it to the site owners (who may not be friendly and may try to prosecute you…), you can try to find a responsible CERT or ISAC for that vertical (who may also not be overly friendly or responsive…) or you can go public with the issue (which is really likely to be unfriendly and may lead to prosecution…). How exactly, do these honorable “white hat hackers” win in this scenario? What is their incentive? What if that web site is outside of the US, say in Thailand, how does the picture change? What if it is in the “dark web”, who exactly do they notify (not likely to be law enforcement, again given the history of unfriendly responses…) and how? What if it is a critical infrastructure site – like let’s say it is an exposed Russian nuclear materials storage center – how do they report and handle that? How can they be assured that the problem will be fixed and not leveraged for some nation-state activity before it is reported or mitigated?
Sound complicated? IT IS… And, risky for most parties. Engaging in vulnerability hunting has it’s dangers and turning more folks loose on the Internet to hunt bugs and security issues also ups the risks for machines, companies and software already exposed to the Internet, since scan and probe traffic is likely to rise, and the skill sets of those hunting may not be commiserate with the complexity of the applications and deployments online. In other words, bad things may rise in frequency and severity, even as we seek to minimize them. Unintended consequences are certainly likely to emerge. This is a very complex system, so it is highly likely to be fragile in nature…
Another issue is the idea of “before bad things happen”. This is often a fallacy. Just because someone brings a vulnerability to you doesn’t mean they are the only ones who know about it. Proof of this? Many times during our penetration testing, we find severe vulnerabilities exposed to the Internet, and when we exploit them – someone else already has and the box has been pwned for a long long time before us. Usually, completely unknown to the owners of the systems and their monitoring tools. At best, “before bad things happen” is wishful thinking. At worst, it’s another chance for organizations, governments and law enforcement to shoot the messenger.
Sadly, I don’t have the answers for these scenarios. But, I think it is fair for the community to discuss the questions. It’s not just Ashley Madison, it’s all of the past and future security issues out there. Someday, we are going to have to come up with some mechanism to make it easier for those who know of security issues. We also have to be very careful about calling for “white hat assistance” for the public at large. Like most things, we might simply be biting off more than we can chew…
Got thoughts on this? Let me know. You can find me on Twitter at @lbhuston.
I stumbled on this great release from the US Department of Justice – a best practices guide to breach response.
Reading it is rather reminiscent of much of what we said in the 80/20 Rule of Information Security years ago. Namely, know your own environment, data flows, trusts and what data matters. Combine that with having a plan, beforehand, and some practice – and you at least get some decent insights into what your team needs and is capable of handling. Knowing those boundaries and when to ask for outside help will take you a long way.
I would also suggest you give our State of Security Podcast a listen. Episode 6, in particular, includes a great conversation about handling major breaches and the long term impacts on teams, careers and lives.
As always, if we can assist you in preparing a breach response process, good policies, performing those network mappings or running table top exercises (or deeper technical red team exercises), let us know. We help companies around the world master these skills and we have plenty of insights we would love to share!
The 6th episode of the State Of Security podcast is now available.
This time around, we get one of the most personal episodes yet – a behind the curtain look of what it is like to manage the incident response team in a highly publicized breach, under strict regulation, for 6+ months. The insights here and examinations of the personal and professional impacts are profound. We also close this episode with our new “shorts” segment – this time with an insight from @sempf. Thanks for listening, and as always, let us know what you think on Twitter – @microsolved or @lbhuston. Stay safe out there!
You can subscribe to the podcast in iTunes or via Podbean. You can also listen below.
Discovering an information security breach can be a shock! Picture it: you are enjoying a regular work day and WHAM! Suddenly you are at the center of an incident that could possibly affect the future of the company and perhaps your own future as well. It’s easy to panic. You know if you don’t do the right thing, right now, bad things are sure to rain down on you. So, what is the very first thing that you should do?
Go immediately to your incident response plan, of course! After all, that is the reason your company has put together an IR plan and team in the first place; to plan for contingencies so that personnel don’t go off half-cocked and lose vital data and evidence.
But is your plan clear enough that regular system users or even help desk personnel know what to do first without having to thumb through a hundred pages of plan? If not, perhaps a simple little trick we use in our incident response plans will work for you.
The very first thing you see when you open one of our incident response plans are employee and incident response team Quick Response Guides (see the example of an employee guide below-the IRT guide is similar, but more complex).
I know from my military experience that having checklists such as the Quick Response Guides in place truly cuts down on mistakes and helps calm personnel during difficult situations. Why not see if they can also improve your response quality?
You can download the pocket guide here.
Thanks to John Davis for this post.
