Getting started with cybersecurity
86% of websites contain at least one serious cybersecurity flaw. You may never experience a single security incident or you may close your business soon because of one. Let’s talk about the cybersecurity basics! Even the top-notch IT companies like Google or Facebook make major mistakes. One day you’re able to remove a comment posted by Justin Bieber , another time sensitive personal information of 77 million users are stolen. The first happened to Instagram, the latter — to Sony. And yes, they do have security departments.
Why on earth would anyone attack my company?
Okay, you may have a little bit fewer than 77 million users. In fact, you may have no users at all, but still – you might be a target.
- your competition;
- that one employee you fired last year;
- someone curious;
What are some goals of potential attackers?
- an information diclosure;
- a sabotage;
- a defacement;
- a challenge / making fun;
- a botnet or cimeware deployment.
You most probably are vulnerable
WhiteHat Security’s research shows that about 86% of websites contain at least one serious cybersecurity issue. Information leak from half of web applications. Every second issue stays unresolved for at least one year. Over 50% of companies don’t bother assigning any person to a system security monitoring. Well, if you don’t secure your systems, you can be pretty sure you’re not a part of those successful 14%.
What is a system? Is it only an application? Of course not. There is a hardware too. And other applications. And an underlying operating system. IoT Devices, people at your company, other systems exchanging information with your system… Lots of it.
Every single part has its own problems but it seems like the biggest one comes with people. A developer or a QA engineer with a lack of security skills, a team with close deadlines, a product owner with no cybersecurity awareness, an external library developer, even a manager, a lawyer or a CEO – you name it.
Another problem is that many people treat security issues like “normal” bugs which they’re not. A security problem is not something (most of) your users will notice. Your application will run just fine. Most of people agree that security flaws have to be fixed. But they constantly procrastinate and eventually forget about the whole thing.
How about the return on investment? Well, you have to sacrifice some of your resources to make sure your systems are secure. But don’t expect any return. There is none. There only exists an unknown probability that someone will attack you and fail because of your improved security. You could similarly ask yourself if you’d buy a life insurance. Yes? So make the investment.
General attack structure
Enough of philosophy. Let’s talk about how an attacker approaches your system.
There are four main parts of an attack.
The first step is to gain as much information about the target as possible. An attacker wants to know everything about the company structure (via Facebook, Twitter, LinkedIn, company’s website, articles etc. and find interesting endpoints, documents etc.
- search engines: Google, DuckDuck.go, Baidu, Bing, Foundstone, Sitedigger;
- programs: nslookup, whois, host.
In this step, the attacker gets to know the system. It’s critical for the rest of the attack.
The points of interest are:
- the server information (OS version, open ports, applications running);
- the application information (libraries, their versions and issues);
- the application metafiles information;
- the network structure (other endpoints, especially with outdated software or test environments).
- search engines like Google, DuckDuck.go, Baidu, Bing, Foundstone Sitedigger and Shodan.io;
- scanners (nmap, OWASP Zed Attack Proxy, WebScarab);
- bug databases (CVE Details, Exploit DB).
The point here could be for instance:
- to get a list of users and their sensitive data;
- create a trap for an administrator or other users;
- gain control over a server.
- OWASP Zed Attack Proxy;
- own code and activities;
- exploits (programs, code snippets) found on Internet.
At this point, the attacker has everything it needs to cause a real damage. The attacker could for instance crack the user’s password and access and/or damage it’s data, remove information from database, put some nasty content on the company’s main page, force your devices to join a botnet and more.
What should I do?
The process of securing your company and/or products is very complex and consists of many levels. It is therefore beyond the scope of this article. I’ll give you however a brief summary of what can be done right now.
Most companies are aware of insecure software consequences, but the teams’ knowledge is usually fragmentary. Security monitoring often doesn’t exist, no policies or procedures are applied, the tests are conducted ad hoc. Wanna do better? Here are some rules you should follow when protecting a system:
Least Privilige Principle
This rule applies to users, processes and applications. They should own a minimal set of priviliges that allow them to accomplish their goals. Watch out for a default configuration too.
Defense in Depth Principle
This one is conceived by NSA. Use more than one protection measure. For example, a common practice is to secure a local network and disable some of the authorization mechanisms inside, so that e.g. a production web site can connect to it’s database without any security check. But what if someone breaks into the network? Here comes the Defense in Depth Principle, saying that you should introduce an additional security measure for this database (e.g. require a user name and a password).
Use only the software your product actually requires to run. An old, abandoned FTP software could make you vulnerable, big time.
Isolate your applications – use virtualization and different accounts when possible.
Segregation of Duties Principle
This rule applies to your development team. Think for instance about who should have an access to your production keys.
Changes made to your system should be auditable. Log a lot!
Hardening your cybersecurity
A great way to improve the system protection is to harden it. A hardening process is a set of rather small changes you have to make to your server configuration that is improving it’s security. You can find more information here.
As Bruce Schneier once said, “security is a process, not a product”. This means that you cannot stop on a single security audit, applications’ update or execution of one set of penetration tests. It also means, you cannot buy it. You have to implement it.
- each person involved in a product development including a product owner, a business analyst and a project manager is aware of cybersecurity’s importance;
- your technical team has an appropriate knowledge required to develop a secure system (it often requires additional training);
- there are assigned people responsible for your sysem security.
On the technical side, the bare minimum you have to do is to:
- keep your applications and libraries up-to-date;
- make sure only required applications run on the server;
- make sure only required ports are open on the server;
- also you can check third party libraries used in application.
In this article, we barely touched a tip of the iceberg which the cybersecurity is. There are lots of topics out there: a security development lifecycle, all these attack and proctection techniques, a threat modeling. I strongly invite you to both attend a professional training and follow this blog as the next article will deal with various resources you can use to get an experience in cybersecurity.