I was recently asked to comment on the compromise, or hack – although I don’t like to use that term in the context of criminal behavior, of a very popular regional website (see my comments here). The site’s homepage was replaced with an image of the Malaysian Coat of Arms and information about who was responsible for the attack. While not a desirable event to endure for any organization, the attack could have been much worse. How? In this case, the site was used for notoriety of the group responsible and not to attack the users of the site (read, the organizations customers and/or it’s data). The down time of the site was minimal, the real site was back online within minutes of the first reports of the defacement. So how does an organization handle such an event? This brings us into the often times confusing world of security. For anyone well-versed in security, and website security in particular, you probably already have several ideas as to what happened. For those not in security you probably have no idea where to begin. Instead of making this another article on the technical measures that can be put into place, I’m going to look at it from the business’s perspective. And in particular, a business that either doesn’t have the security professionals on staff or has hired out their technology services and therefore rely exclusively on a third-party.
There are several things a business needs to understand when managing their website. The first is that they’re ultimately responsible for their website’s security. Whether this is in house or contracted through a third-party, it’s the businesses responsibility to ensure that their customers are safe when using their website. Regardless of how the organization has their website developed, another important issue to understand is that not everyone involved in developing websites has the knowledge and skills necessary to create secure websites. This may be our industries dirty little secret, but I find more web developers that can’t answer basic website security questions than those that can. To compound this further, security in the development life-cycle of website (and application in general) development is often over-looked, minimized or disregarded all together. We have created an environment where software has to be developed and released so rapidly that security is oftentimes left on the cutting room floor. Finally, it is very difficult to write 100% secure websites – I would argue that it’s next to impossible for any site that exhibits functionality. What we are left with is a perfect storm to create insecure websites. So what can a business do?
In short, be prepared to respond. This is commonly referred to as incident response. Accept that there likely exists a security vulnerability in your website and that at some point, an attacker will compromise it. Ensure that your business and those that support your site are ready to respond. That they’re able to identify a compromise has occurred and able to restore your site to a known good state quickly. This isn’t to say give up, be engaged in your websites security but also be ready to react. Some items to consider in order to ensure this happens, in no particular order:
- The data your website utilizes is backed-up. If the site is compromised and you can’t trust the underlying data it will be restored to the last known good back-up. This means you can lose data so make sure you understand your backup schedule and the risk it exposes you to. If you only have a weekly backup of your site you may lose a lot of data!
- There exists a back-up of your site. This is commonly accomplished by using version control. The team managing your site should be able to restore the site to the most recent version using a clean source, that is, from a place where the bad guys should not have been able to get. The vulnerability may exist in this code so it’ll be important to identify where the compromise came from, we’ll discuss that shortly.
- There exists an on-call or notification system to alert those that manage your website that an event has occurred and they can begin fixing the issue. The longer it takes them to swing into action, the longer you (and your users) are exposed. Proactive monitoring is best and hopefully the team you work with is already doing that.
- Get post attack information. It’s not enough to have your site fixed, you need to request a report that lays out how the compromise happened, and more importantly, how it was fixed. Even if you don’t understand the technical details, you should receive an explanation of how it is being addressed – this will either erode or bolster your confidence in your website team.
- Think through potential scenarios and discuss, as a business, how you would respond. Do you put out a press release or ignore that it happened? Can you identify if customer data was stolen? If not, why not? Has your site been distributing malware? How will you know? Go through these scenarios not only as a business, but also with your website team and come up with contingency plans to deal with them. These plans won’t always reflect 100% the actual attack, but they’ll go a long way in preparing for the worst!
- Not all compromises are as apparent as a home page defacement. In fact, most bad guys go to great lengths to remain undiscovered. Sites can be compromised for months before someone realizes that it has occurred. Security doesn’t begin and end with the development of the website, it’s a never ending process that needs to be accomplished all day, every day. Bad guys use sites to steal data, distribute malware/spam and other common criminal activity. This activity leaves traces and a good security team can identify them. Make sure that your website team is actively monitoring your site’s activity to identify and address if a compromise has happened. Try to be proactive and not reactive.
- Don’t use the excuse that technology is not your realm. If you’re using technology than it is your realm. Educate yourself on how websites work and be able to have meaningful conversations with those that manage it on how to secure them.
While this is by no means an exhaustive list, I would be very encouraged as a website developer if all of my clients engaged in conversation with me about these issues. As a security practitioner I would feel remiss if I didn’t mention that website security is just one component. There are additional layers of security that go well beyond what we discussed here, namely, where the site is hosted. Hosting environments can be compromised and the results can make it difficult to determine how the bad guys were able to get in. While this is a slightly different conversation, many of the same principals apply – be able to engage the team that provides this service to you in meaningful conversation about their security practices. Being proactive will go a long way in better protecting your website!