Keep it Simple: Creating an Incident Response Policy

Drafting an Incident Response Policy can seem overwhelming. At the beginning, it doesn’t seem feasible that a single document can help you maintain order during a breach. You may ask yourself if it’s even possible to prepare your team for responding to all of the latest Tactics, Techniques and Procedures (TTP) that attackers are leveraging. It’s not possible to craft a document that addresses every possible threat individually. However, you can create an effective policy that covers each major threat category as opposed to each individual attack.

If you’re not sure which categories to focus on, I recommend taking a look at Microsoft’s STRIDE Threat Model. STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. By leveraging the STRIDE model (or any other threat model), you can create a policy that will be relevant for years to come. This “one size fits all” approach will not only make your policy more efficient, it will be much more effective.

After you’ve crafted your policy, be sure to take the time to walk through a few scenarios. It’s even worthwhile to bring in a 3rd party to help you simulate a computer security incident on a regular basis. This exercise can help you identify any gaps that exist within your policies and procedures. It will also demonstrate how a simple policy will help your company respond to the even the most complicated security issues.

Providing Security to a Grumpy End-user

Working in IT, one of my biggest challenges has been to convince end-users that it is worthwhile to forego a convenience in the name of security. Regardless of whether it’s requiring the use of multi-factor authentication or forcing a computer to auto-lock after a certain amount of idle time, it often boils down to the end-user facing some sort of hinderance to their productivity. I completely understand their frustrations. I’ve managed Active Directory networks that served around 15,000 people and still managed to lock out my account. Was I annoyed? Absolutely, but I understood the need for the control. If you take the time to explain security to the end-user, they’ll be more likely to understand your decisions.

Here are some tips I’ve found to be helpful when convincing an end-user to implement a security control:

  1. Remind – Remind them that you’re not making this change just for fun. It’s being completed to reduce the likelihood that your organization’s systems will be compromised by an attacker.
  2. Example – Give an example of a high-profile breach that could have been prevented by implementing this control. It’s likely that they’ve had their personal information exposed as a result of a breach within the last few years. Even if they (somehow) haven’t personally been affected by a data breach, they have a friend or family member who has. Using an example of something that has affected them personally will go a long way to helping them understand why it is worthwhile to implement a security control that could have an adverse affect on their productivity.
  3. Analogy – Still having trouble rationalizing why you’re implementing a new security system? Try to use an analogy to describe how the new control will help prevent an issue. For example, if they are upset that they can’t reuse a password across multiple systems, remind them that the key to their Ford vehicle won’t work on ALL Ford vehicles.
  4. Describe –  Take some time to describe why you’re implementing the new security control. It’s important to make the effort to explain the task in terms that the end-user will understand. Don’t use the complexity of the topic as an excuse. If you can’t explain the issue to a non-technical employee, chances are, you don’t understand it yourself.

DDoS Attack: Are You Ready To Respond?

A distributed denial of service attack is a malicious attempt to make machines, applications or other network services unavailable to legitimate users. There are many types of DDoS attacks including SYN and UDP floods, reflected attacks, application attacks and multi-vector attacks that employ several types of attacks in combination. In the past, it was typical for businesses to accept the risk of DDoS attacks since they were relatively rare and small scale. But that has all changed in recent years; both the number and scale of DDoS attacks have increased dramatically. Because of this trend many savvy businesses have changed their philosophies and taken steps to mitigate DDoS attacks. Unfortunately, this trend is far from universal. Many businesses remain complacent and have done little or nothing to prepare for DDoS attacks. Is your business one of these and if so, what should you do about it?

The first step I recommend taking is to perform a basic risk and impact study on the subject: how likely is it that my business will be attacked, and if it is, how badly will it hurt us? If the answer to either of these questions is unacceptable, then you should certainly move on to step two and start the process of incorporating DDoS into the incident response plan. In a nutshell – develop the policy language, include likely DDoS attack indicators and attack scenarios in the plan, develop specific strategies to counter these attacks, assign responsibilities to specific individuals and practice the plan. Sounds easy, but how do we go about doing that you may ask. Here are some basic tips:

• Contact your ISP. Get their advice, find out about their experience and capabilities with DDoS attacks, find out about any anti-DDoS tools they might have available and their cost, etc. If you don’t do anything else, at least take this step. You probably won’t be able to do much at all to counter a DDoS attack without your ISP’s help.

• Ensure that your team is fully aware of all the capabilities your present equipment and infrastructure has for handling DDoS attacks.

• Ensure that your IR and IT teams are aware that DDoS attacks are sometimes persistent and can last for days, weeks or more. Make plans for keeping your reactions strong and timely.

• Employ centralized logging and ensure that proper monitoring procedures are in place and reviewed.

• Make sure you maintain a whitelist of source IPs and protocols, major customers, critical service providers and partners that must be allowed access during attacks.

• If you are at high risk and impact levels for DDoS attacks, consider improving your infrastructure and/or employing specialized DDoS services or products. Cloud based servers, for example, have great capabilities for fighting DDoS.

• Ensure that applications, networks and operating systems that may be targeted in DDoS attacks are fully hardened.

Here’s hoping that no one out there targets your business with a major DDoS campaign. But if you think the possibility is high, better take a tip from the Boy Scouts and be prepared!

IoT Privacy Concerns

Lately, I’ve been amazed at how quickly the Internet of Things (IoT) has become a part of my life. Everything from speakers to a Crock-Pot (yes, a Crock-Pot) has been connected to my home wireless network at some point. As much as I enjoy all the conveniences that these devices provide me, I always consider the security implications prior to purchasing an Internet-connected device. It’s worthwhile to weigh the convenience of installing new Internet-connected equipment vs. the privacy issues that can occur if the device is compromised.

There have already been a variety of security issues stemming from the widespread adoption of IoT devices. Last fall, a website published links to over 73,000 unsecured camera throughout the world. These cameras monitored everything from shopping malls to people’s bedrooms. Without implementing proper controls around IoT devices, we will continue to see similar issues arise.

I don’t intend for this blog to scare people away from purchasing IoT devices. In fact, I will provide you with a few simple changes you can make to your IoT configurations that will reduce the privacy issues that can occur by installing an IoT system. These changes won’t necessarily diminish the conveniences you can gain by buying an Internet-connected thermostat or installing the latest IoT security camera. However, they will significantly reduce the risk associated with installing an IoT system.

A few recommendations for your new gadget:

  • Change the default password  – A majority of the aforementioned cameras were compromised because the owners did not change the system’s default password. By simply setting the password to something that will be difficult for an attacker to guess, you can reduce the risk of someone compromising your device.
  • Segment – Try to isolate your IoT devices from the rest of your home network. It is very possible that an attacker would use an IoT system as an entry-point to gain access to other systems.
  • Check for software updates – Make a routine to check for software/firmware updates for all of your IoT devices. These updates will often contain a security patch that can protect your system from being exploited.
  • Do not expose the device directly to the Internet – There shouldn’t be a need to expose an IoT device directly to the Internet. This will provide an attacker a much larger surface to attempt to exploit your device. If the system requires that configuration, it is worthwhile to consider another option.

Windows Server 2003 – End of Life

Windows Server 2003 has officially reached it’s end-of-life date. Does this mean that all of your Windows Server 2003 servers will be hacked on July 16th? Probably not. However, it is worthwhile to ensure that your organization has a plan in place to migrate all of your applications and services off of this legacy operating system. This is especially true if you have any Windows Server 2003 systems that are exposed to the internet. It is only a matter of time until a new vulnerability is discovered that affects this operating system.

As a former Windows Systems Administrator, I understand how difficult it can be to convince an application owner to invest the time and resources into migrating a system or service to a new operating system. Despite the fact that these systems have a heightened risk of being compromised, it’s very possible that your organization doesn’t have the financial resources to migrate your applications and services to a new operating system. You’re not alone. I found over 1.3 million servers running IIS 6.0 in Shodan. Over 688,000 of these servers are in the United States. However, there are still ways to reduce the risk of hosting these legacy operating systems until a migration plan is put into place.

A few ways to reduce the risk of hosting an application on a legacy operating system are:

  • Discover and document – You can’t protect a system if you don’t know it exists. Take some time to identify and document all of the legacy and unsupported operating systems in your network.
  • Learn about the application – Take some time to learn some details about the application. Is it still even being accessed? Who uses it? Why is it still hosted on an unsupported operating system? Are there other options available?
  • Educate the business users – If financial resources are an issue, take some time to explain the risks of hosting this application to the business users. Once they gain an understanding of the risk associated with hosting their application on a legacy OS, they can help secure funding to ensure that the application is upgraded.
  • Isolate – Segmenting the legacy system can reduce the risk that it is accessed by an attacker. It also can decrease the likelihood that a compromise of the legacy system will spread to other servers.
  • Update and secure – Install all available patches and updates. Not only for the operating system, but the hosted applications as well.
  • Perform thorough log analysis – Implement some sort of centralized logging platform to ensure you have the ability to detect any anomalies that occur within these systems.
  • Plan for the worst – Be prepared. Have a plan in place for responding to an incident involving these systems.

DOJ Best Practices for Breach Response

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!

OPM Data Breach: Food for Spear Phishing and Blackmail

The news just came out that the OPM data breach was even more serious than was first announced. The toll has risen from 4.2 million to the present total of 22.1 million people – nearly seven percent of the US population. They are now saying that nearly 2 million of these aren’t even people who have applied for security clearances themselves, but are spouses and other people close to applicants. What a wealth of information for cyber-criminals!

One of the things that make this such a bad hack is the kinds of information that may have been revealed. Background checks, depending on the level of clearance that is being applied for, can delve into an individual’s past quite extensively. Information such as all your past addresses, who you associated with, who your teachers were, the periodicals you read, your medical history, your arrest records, the organizations you associate with, etc., etc. Just the sort of juicy information that Spear Phishers dream of! But worse than that, this is the sort of information that can be used to blackmail people.

Blackmailing is probably the most dastardly type of social engineering there is. Here you are; nice family, good job, couple of kids, respected in the community – life is sweet! Then all of a sudden, someone contacts you and threatens to release some scurrilous information to the public if you don’t do as they say. Maybe you were arrested for something embarrassing such as being caught as a Peeping Tom. Maybe it lists a past relationship that you were not candid about with your spouse. Maybe it’s an embarrassing medical condition such a venereal disease. Or maybe it’s some really bad dirt concerning your spouse or another family member. Whatever it may be, suddenly you are faced with the choice of cooperating with criminals and breaking the law or abject ignominy – what would you do?

It’s amazing how many people will actually cooperate with their blackmailers and do their bidding. Even if it means jail time! Either alternative seems so bad to the blackmailed that they just can’t face either. So they go along in the desperate hope that nobody will find out and the whole mess will just go away. Good luck!

The way to deal with this problem, in my opinion, is to give them a third choice. Agencies and organizations should set up programs that offer forgiveness and help for these individuals if they come forward. Make sure that your personnel are aware of the possibility of blackmail, explain the forgiveness program to them, and make them understand that no matter what, they are better off reporting the incident than submitting to intimidation.

State Of Security Podcast Episode 6

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.

OPM Debacle: Today All Business & Government Leaders Should be Computer Security Savvy

If you want to be in direct command of a U.S. aircraft carrier you must be a pilot or navigator. There is a very good reason for this. Despite the fact that there are thousands of personnel on these ships, many with very responsible jobs indeed, what really counts are the aircraft and the pilots that man them – and the Navy knows it. They also know that if they want the mission to be carried out successfully they need an individual in charge with all the right knowledge and perspective to support these most valuable assets. Not a captain that made his rank by being a wiz at logistics!
Some of this same wisdom should be applied to leaders of government agencies and businesses that store and process private information. Do we really want people running our organizations who are not well versed in computers and information security? After all, these machines are not only vital components of our business practices; they hold the keys to the kingdom as well!
Take the recent Office of Personnel Management (OPM) debacle as an example. This agency had been warned repeatedly about the lack of security in their systems, but little or nothing was done about it. Result: four million personnel files compromised. That’s one out of every 80 people in the country! And the reason for this failure seems to be simple ignorance and inexperience on the part of staff.
One lesson that has become brutally apparent from my risk assessment experience is that if upper-level management isn’t behind the effort, the risk assessment is doomed to fail. I’m sure this is true of general information security programs as well; if upper-level management isn’t knowledgeable and interested then the information security program is doomed to fail – and the bigger and more entrenched the bureaucracy the more this is true.
Now, I’m not saying that I think all CEOs should be recruited from the ranks of IT security. What do most of us know about running a big organization? What I am saying is that I think a certain level of expertise in matters computer and security should be a requirement of any job that oversees the processing and storage of our private information. Especially since computer systems are going to become increasingly vital parts of our everyday lives as time goes on.

Are you hacking!? There’s no hacking in baseball!

My Dad called me earlier this week to ask if I heard about the FBI’s investigation of the St. Louis Cardinals. My initial reaction was that the investigation must be related to some sort of steroid scandal or gambling allegations. I was wrong. The Cardinals are being investigated for allegedly hacking into the network of a rival team to steal confidential information. Could the same team that my Grandparents took me to see play as a kid really be responsible for this crime?

After I had time to read a few articles about the alleged hack, I called my Dad back. He immediately asked me if the Astros could have prevented it. From what I have read, this issue could have been prevented (or at least detected) by implementing a few basic information security controls around the Astros’ proprietary application. Unfortunately, it appears the attack was not discovered until confidential information was leaked onto a pastebin site.

The aforementioned controls include but are not limited to:

  1. Change passwords on a regular basis – It has been alleged that Astros system was accessed by using the same password that was used when a similar system was deployed within the St. Louis Cardinals’ network. Passwords should be changed on a regular basis.
  2. Do not share passwords between individuals – Despite the fact that creating separate usernames and passwords for each individual with access to a system can be inconvenient, it reduces a lot of risk associated with deploying an application. For example, if each member of the Astros front office was required to have a separate password to their proprietary application, the Cardinals staff would not have been able to successfully use the legacy password from when the application was deployed in St. Louis. The Astros would also have gained the ability to log and track each individual user’s actions within the application.
  3. Review logs for anomalies on a regular basis – Most likely, the Astros were not reviewing any kind of security logs surrounding this application. If they were, they might have noticed failed login attempts into the application prior to the Cardinals’ alleged successful attempt. They also might have noticed that the application was accessed by an unknown or suspicious IP address.
  4. Leverage the use of honeypot technology – By implementing HoneyPot technology, the Astros could have deployed a fake version of this application. This could have allowed them to detect suspicious activity from within their network prior to the attackers gaining access to their confidential information. This strategy could have included leveraging MSI’s HoneyPoint Security Server to stand up a fake version of their proprietary application along with deploying a variety of fake documents within the Astros’ network. If an attacker accessed the fake application or document, the Astros would have been provided with actionable intelligence which could have allowed them to prevent the breach of one of their critical systems.
  5. Do not expose unnecessary applications or services to the internet – At this point, I do not know whether or not the Astros deployed this system within their internal network or exposed it to the internet. Either way, it’s always important to consider whether or not it is necessary to expose a system or service to the internet. Something as simple as requiring a VPN to access an application can go a long way to securing the confidential data.
  6. Leverage the use of network segmentation or IP address filtering – If the application was deployed from within the Astros internal network, was it necessary that all internal systems had access to the application? It’s always worthwhile to limit network access to a particular system or network segment as much as possible.

Honestly, I hope these allegations aren’t true. I have fond memories of watching the Cardinals win the World Series in 2006 and 2011. I would really hate to see those victories tarnished by the actions of a few individuals. However, it’s important that we all learn a lesson from this..whether it’s your email or favorite team’s playbook…don’t overlook the basic steps when attempting to secure confidential information.