Security Audit for Dummies

A security audit is the final and most relevant step in implementing security defenses.

When you build your service, you must remember to make it as safe as possible. The bigger it is, the more urgent its security is.

The first step is to run a risk analysis to find possible holes and find out what type of attacks you can expect.
The second step is to develop a proper policy to defend against them.

Finally, you undertake a security audit to check if it works.

What type of tests can we use?

Penetration Testing

We can use penetration testing (informally pen test) to check for possible attacks.

They are controlled attacks that look for security weaknesses. Their goal is to check our security system against known possible threats and return the report (what do we need to improve?).

We can identify which defenses are effective and which ones (if any) are defeated and need to be fixed.

A penetration test target may be either a white box (which provides background and system information) or a black box (which provides only basic information or no information except the company name).

We’ve compiled some Websites and Tools that can help you learn more about Penetration Testing:

Distros

Kali Linux
Parrot Security OS
PentestBox Windows

Tools

Metasploit
w3af
Wireshark

Tutorials and Training

Kali Tutorials – Pen Testing for Beginners
Offensive Security Online Training

Blogs

Sans Pen Testing Blog
Offensive Security Blog
Pentest Mag Blog

Risk-based testing (RBT)

In this kind of test, we prioritize and emphasize the most significant risks to us.

With this knowledge, we can choose and prepare proper tests during test execution.

We can call “risk” to an undesirable outcome we aim to prevent. There is not always enough time to efficiently check all security areas, so risk-based testing concerning the functionality of the systems with the highest impact and probability of failure can be the best choice.

We can summarize the whole idea of Risk-based testing in a few points:

• It starts at the early beginning. We try to define the most dangerous threats. With this knowledge, we try to prepare proper plans for testing.
  
  

• As it accompanies us during the development process, it helps reduce the likelihood of defects and create working workarounds (and testing them).
  
  

• Define the most dangerous threats to us and which ones we still have to work on.
  
  

• It measures how well we are doing in reducing the probability of failure. If we know we can’t deal with something, we can search for tools and people to help.
  
  

Most common type of attacks

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a simple attack. It uses two facts.

One, communication between server and client is based on requests.

Two, cookies are sent automatically to the server.

CSRF attack allows an attacker to execute authenticated actions without user knowledge and approval. It depends mainly on forcing the browser to execute malicious requests and using a user logged-in status.

Cross-site Scripting (XSS)

Another type of attack is Cross-site scripting (XSS), in which malicious scripts are injected into theoretically trusted websites. It could be JavaScript, it could be, for instance, VBScript.

The main thing is it may be run in the browser. As a result, an attacker can execute any script he wants. It can be injected very easily using a comments system for example. You post a comment with a JavaScript code and if the server doesn’t do anything about it, it will execute your malicious code as well.

SQL Injection

While XSS works on the client side, SQL Injection uses databases. SQL Injection attack uses the form system to manipulate the data. Let’s say your query looks like this:

DELETE FROM Users WHERE id = '$_GET['id']'

If the attacker changes the proper id to the string like this '1' OR '1'='1', your query will look like this:

DELETE FROM Users WHERE id = '1' OR '1' = '1'

As a result, it will delete all the users from the table. To understand this better, you can watch a Computerphile video.

Denial of Service (DoS)

The Denial of Service (DoS) is a type of attack that is focused on making a resource unavailable. It uses a mechanism of sending a massive amount of requests to the server making it incapable of returning the result.

It’s a common attack and not so hard to prepare. It’s often hard to defend against it because defining if a request is valid or if it’s an attack is not always so easy. Learn more about DoS:

How to prevent the attacks if you’re not an expert?

Use solid solutions

Don’t try to reinvent the wheel and do everything your way. Before building your application try to find a solid base. Check for secure and popular JavaScript frameworks and IT security frameworks.

They’re often made by experts and their popularity makes them secure. No one is perfect, but if they’re checked every day by their users, the holes and errors are easy to eliminate.

Deciding to stick with your hand-made framework could bring a lot of harm if an attack occurs. You can also use security frameworks to help yourself in security auditing.

Try popular tools

Don’t be afraid of using the captcha mechanism, testing automation tools, and so on. There are many of them on the market.

You could check SoapUI and TestingWhiz.

External professional security team

It’s the most expensive case but surely the best one.

Try to find an expert to back you up in terms of security. It can be really useful. He will always see a lot more than you because he knows more about the threats out there. If you can’t afford an expert for the development process, try to find him after finishing the job.

Make him check security and do a quality security audit.
If the results aren’t perfect repeat the whole process. It’s pointless to carry it and ignore the results. Also, don’t check only for holes.

Check the efficiency of the security-improving solutions.
For instance, if you deploy a strong password-changing policy, make sure there is no way to bypass this function. Let’s say you require changing passwords every week. If you don’t design it well, you could, for instance, give the user the possibility to change it just only to return to the old password after a minute.

Has the password been changed? Yes! But… it won’t do any good.

Try to be as detailed as you can.

Check for everything, not only for the most common type of attacks. Even big names we all have heard of have been the victims of imperfect security systems. Thus, it is certainly not a piece of cake.

Conclusion

Does good security auditing make you completely secure? Not really. They say, your security audit is as good as the auditors, but there aren’t perfect tools and perfect people. However… try to make it as safe as possible.

If you are going for a poor audit, better to not do it at all. Weak security auditing can leave you with a false sense of security that is extremely dangerous for your organization.

So, if you do it (and you should), try to be as effective as you can.

There can be no shortcuts! Use the best tools, hire the best auditors, do the most detailed audits, and don’t try to save some money here! If you save it now, there’s a very high risk of losing it in the future.