Security 101: Internal Threats
If you follow tech news you will likely have seen by now that some high profile Twitter accounts were used for a Bitcoin scam. There was a lot speculation what happened before Twitter posted an early update of their investigation. The Times also published an interview with people who seem to be involved. This event raised a lot awareness for internal threats, so it seems like a good time to address them in the Security 101 series.
Over the last ten years I have not worked with one startup that was actually aware of internal threats being a thing. I mentioned them a few times in past articles in this article series as they are not only misunderstood – or simply not acknowledged at all – but also extremely hard to guard against. The really tricky part is that they are mostly irrelevant for you until they suddenly become relevant and turn into a big deal.
Before jumping into more technical details and steps you can take to prevent, mitigate or at least detect problems origination from within your organisation let us talk about the two different problems we will cover:
1.) Social engineering and phishing. If you thought only your users might fall for those two you are in for a surprise. There is a reason why Google moved from TOTP based two factor authentication – and did not even consider SMS an options as the risk for SIM swap attacks is not negligible – to security keys and seems to have eliminated phishing as an attack vector. People will sometimes make mistakes and once you have an account it becomes easier to gain additional access.
2.) Bribes. This does not only happen in movies. The more interesting as a target you are and the more lucrative it seems to breach your system the easier it will be for an attacker to spend money for some form of access. No matter if it is one of your customer support representatives who already was planning to leave your company and sees an easy way to get an additional year of salary this way or your catering team snatching a laptop off a desk. Once an attacker is able and willing to spend serious money things become really tricky.
Both of threats are usually not relevant to many companies until they are. You might hit hockey stick growth overnight and suddenly your company is worth three social networks or you might just have created an innovation which might disrupt a large market. You start to grow rapidly, onboard new people and suddenly those two attack vectors exist in an amplified state. When your company only consists of two technical founders they are already present, but the chances for them to become a problem are hopefully significantly smaller.
As previously mentioned, using a security key will bring you a long way. They are relatively inexpensive, there are tutorials and libraries to integrate them with most stacks and they work on desktops, laptops and mobile. Eliminating phishing – or at least reducing chances significantly – will be a huge step in the right direction. But as we already established this is only one part of the problem we are facing.
As you grow one of your most valuable tools beside common sense will be a solution for Security Information and Event Management – aka SIEM. But it will take some time to get there. And you will need an experienced team who actually knows how to configure it properly. Luckily we can get some of the benefits with a lot less work and less expensive systems.
At its core you want two things: collect all your logs in one place and detect if something looks wrong. You obviously want a notification if you detect something.
Defining what „wrong“ means in this context is hard. Especially when starting out and not having a good data set. Or an idea how users actually use your product. Worst case you define „wrong“ wrongly – sorry, I had to get this one in – and end up throwing alarms for legit events every five minutes. This will most likely lead to people ignoring alarms after a day and all the value you can get out of your system and later on a full blown SIEM is gone. Or you simply do not detect anything. So all you do is burning CPU cycles running a system without value. SIEMs – even systems only providing part of the functionality – are hard.
To give you an idea for the incident we have seen with Twitter:
- multiple (therefore high profile) accounts tweeting the same or mostly the same message in a short timeframe
- multiple accounts resetting their password
- an employee changing a password or 2 factor authentication status of an account
In hindsight those rules are obvious, but how many of those would you have setup without the incident? The first two are relatively hard to fine-tune. How many are „multiple“? What is „the same message“? What happens at New Year’s Eve?
The last one on the other hand is something you should always setup. Even if you hardcode the rule in your app. If anyone touches sensitive customer data which can lead to an account takeover, send a message to everyone who might be on call or engineering.
It would be even better if you do not make this feature accessible in a straightforward way. Make people jump through hoops like two people confirming the removal of two factor authentication. You obviously add work and service cost, but you also make exploiting this functionality which might actually be used for customer support way harder.
On the technical side I already mentioned hard coding the most important alarms into your system. This works well until engineering is compromised. But when you get to this point you have to worry about so many things that it is nearly game over for a regular startup. A little bit more sophisticated would be writing all your logs to a managed database or data store like S3. A small server can parse those logs checking for pre-defined events and sending you an email or a Slack message. While this is not highly available, might blow up from time to time and is quite a bit additional work, it is a solid foundation to build on. What I have seen most startups do is pay a lot money for a SIEM without accomplishing anything beyond what the basic alerting system we talked about is capable of. This is understandable as they lack time to get familiar with a tool complex tool in a domain they do not know.
As with many things we are discussing here, it is just a start. It will not be the last time you have to invest time and money in this part of your system. The more customers you have, the more data you store, the more relevant your application or platform becomes, the more important logging and alerting will become.
One of the most unpredictable threats you will face will be of internal nature. Your employees, coworkers and consultants and anyone entering your premise will become a potential attack vector. And as unpredictable is not enough, most of your mitigation strategies will result in you making everyone’s life harder. As you can imagine you will not be their favourite person when you roll out required changes. But this is sometimes the price to pay to ensure to keep your company and data safe and secure.