,

Gain more insight and create doomsday scenarios for better threat modeling

In previous blogs you could already read about what threat modeling is, and about the 4 steps. In practice, however, threat modeling is more than just a technical analysis of your application. The threat landscape is constantly evolving, and so is your organisation. Therefore, you need to understand the technical and business context, and create doomsday scenarios. As a result, you have a broader insight of the threats to your application.

  1. The ecosystem

Applications are not always stand-alone. On the contrary: they are mostly part of an ecosystem of applications. You need to find out how it works and how it supports your organisation. You also need to have a clear understanding of the security requirements. You should, for example, know what other applications or services the application is exchanging information with.

  1. The business context

What business process is being performed or supported? What are the characteristics of that specific process? And how crucial is that process for your business? You also need to find out who is using the application and identify possible threat actors. In most cases, they fall into one of the following categories:

  • Insider trusted: privileged users
  • Insider untrusted: very regular users, contractors …
  • External trusted: suppliers, partners, service providers …
  • External untrusted: competitors, cybercriminals …

Eventually, you need to identify risks for your business: what is the impact and what is the probability that a certain risk will occur?

  1. The added value of threat modeling

Threat modeling is quite time-consuming and thus expensive. It is therefore only relevant for important applications: those that bring in a lot of revenue or handle important data for your organization.

  1. Create doomsday scenarios

 Doomsday scenarios are hypothetical situations: the worst that could happen for an application – and for your business. Creating doomsday scenarios helps you to proactively anticipate – and even prevent – possibly catastrophic events. You need to describe the following:

  • Threat sources: who would be interested in compromising the applications? Why would this be interesting for an attacker?
  • Impact: what will be the impact of an attack? Some of the possibilities are theft, loss, corruption and disruption.
  • How: how will the scenario be realized? Describe in detail how the attack would be performed.

These scenarios give feedback on your current security situation. You will discover more potential risks and steps to be taken to reduce these risks.

Could you use some more explanation? Click here to download our free ebook.

Security of Normalized Systems

I had an interesting conversation with Prof. Dr. Jan Verelst of the University of Antwerp. They (Prof. Dr. Jan Verelst together with Prof. Dr. Herwig Mannaert) created the theory of normalized systems.

A normalized system is created following a set of rules, which ends up making the software as ‘atomic’ or ‘modular’ as possible. Software modules are split up to the smallest units possible. This creates software that has no ‘ripple effects’, meaning that updating a part of it, adding functions and features, or changing underlying systems needs minimal effort. Software stays nimble and changeable.

After working many years on the theory, they started NSX to bring this concept to market. They have now had several successful projects. I am interested to see if the promise of making systems nimble and easy to change comes true.

Our conversation was about how normalized systems relate to security. In effect, a NS is not secure by default, but there are quite a few benefits when it comes to security:

  • if a flaw is found in the code expander (the ‘blueprint’ of a piece of code), fixing the expander allows for all software based on it to be easily updated to the newer, safer version
  • if there is a problem with the underlying system (OS or hardware), the code can be generated quickly for a different system
  • if a developer introduced a problem in the (limited) human generated code, it is easily tracked and replaced without effects on other modules, since the modularity is so extreme

All in all, I expect great thing from NS. Making code modular doesn’t automatically make it more secure, but it limits the damage and makes it easier to fix.

,

Embedding GDPR in the secure development lifecycle (SDLC)

Did you know that the GDPR and SDLC re-inforce each other and that the GDPR can be used as the ideal business case to start with SDLC? Siebe and I explained how and why during the OWASP AppSec Europe conference in Belfast. Couldn’t attend? You can find the presentation in our previous blog, or begin by reading the introduction below.

We all know that in less than a year the GDPR (General Data Protection Regulation) enters into force to unify the privacy legislation within Europe and the UK and improve the protection of personal data and data subject rights. And I don’t need to tell you that the secure development lifecycle (SDLC) method is thé go to methodology when planning for, designing, building, testing and delivering information systems. But if you play it smart, you can improve your SDLC by including GDPR activities and use SDLC artifacts to demonstrate compliance with GDPR.

A lot of articles in the GDPR specifically refer to security. Article 25 for instance, on privacy by design & default, article 32 on Security of Processing and article 35 on DPIA’s all specifically mention the security levels and assessments that should be considered. The most efficient way to comply with these GDPR security requirements when developing (new) applications, is by integrating them into your Secure Development Lifecycle.

You can find more information on the OWASP Software Assurance Maturity Model (SAMM) and how it can be integrated into any existing SDLC here. For now, it suffices if you know that OpenSAMM is defined in different levels.

  • At the highest level it is divided into four tasks or concerns to consider while developing or using software. They align well with a typical organisational structure, and this is how software security typically ties into an organisation.
  • At a lower level, several security practices are defined that should be considered for improving software security.
  • At the lowest level, every security practice consists of a set of activities, ordered in maturity levels or objectives.

The GDPR articles related to security fall perfectly into these activities. Just check out this table:

SAMM domains

 

So, when you divide for example the GDPR requirements on Policy & Compliance into three objective levels, this is the result:

PolicyCompliance

More examples and details can be found in the presentation in our previous blog. Or get in touch!

 

,

Presentation “Embedding GDPR in the SDLC” available for download

Last week Thursday we delivered our presentation “Embedding GDPR in the SDLC” at the OWASP AppSec Europe conference in Belfast.
The presentation is the outcome of various projects where we encounter both privacy and application security challenges.
Siebe De Roovere (one of our privacy specialists) and myself have worked on integrating GDPR compliance requirements in a secure development life cycle.

SAMM – GDPR mapping

For secure development life cycle projects we use the OWASP Software Assurance Maturity Model (SAMM). This is an excellent maturity model with concrete guidance on application security activities. You can integrate these activities in your software governance, development, testing and operations. We identified the GDPR requirements and deliverables and mapped these on the SAMM activities.
This way we improve both software security activities and can demonstrate GDPR compliance with the security deliverables. One example is a documented threat model , that includes the outcome of a data privacy impact assessment.

Download

There was a lot of interest for our session and we had great questions and feedback at the end of our presentation.
The slides of the presentation are available for download here: TOREON_Embedding_GDPR_into_the_SDLC_OWASP_AppSecEU_Sebastien_Siebe_V20170511
We will let you know when the video of the presentation is available.

We decided to donate the SAMM/GDPR mappings to the OWASP SAMM project and will organize a working session during the upcoming OWASP Summit in June to develop this further.

In the mean time: we do encourage you to provide us feedback and/or input to improve the current mappings!

Kind regards,

Seba & Siebe

,

Seven advantages of penetration testing

In a previous blogpost we explained what penetration testing is and how it can help improve your security. Time to take a closer look at the 7 benefits pentests have for your company.

  1. Reveal vulnerabilities

Penetration testing explores existing weaknesses in your system or application configurations and network infrastructure. Even actions and habits of your staff that could lead to data breaches and malicious infiltration are being researched during penetration tests. A report informs you on your security vulnerabilities so you know what software and hardware improvements you have to consider or what recommendations and policies would improve the overall security.

  1. Show real risks

Penetration testers try to exploit identified vulnerabilities. That means you see what an attacker could do in the ‘real world’. They might access sensitive data and execute operating system commands. But they might also tell you that a vulnerability that is theoretically high risk isn’t that risky at all because of the difficulty of exploitation. Only a specialist can perform that type of analysis.

  1. Test your cyber-defence capability

You should be able to detect attacks and respond adequately and on time. Once you detect an intrusion, you should start investigations, discover the intruders and block them. Whether they are malicious, or experts testing the effectiveness of your protection strategy. The feedback from the test will tell you if – but more likely what – actions can be taken to improve your defence.

  1. Ensure business continuity

To make sure your business operations are up-and-running all the time, you need network availability, 24/7 communications and access to resources. Each disruption will have a negative impact on your business. Penetration tests reveal potential threats and help to ensure that your operations don’t suffer from unexpected downtime or a loss of accessibility. In this respect, a penetration test is quite like a business continuity audit.

  1. Have a third party expert opinion

When an issue is identified by someone within your organisation, your management may not be inclined to react or act. A report from a third-party expert often has a bigger impact on your management, and it may lead to allocation of additional funds.

  1. Follow regulations and certifications

Your industry and legal compliance requirements may dictate a certain level of penetration testing. Think about the ISO 27001 standard or PCI regulations, which requires all managers and system owners to conduct regular penetration tests and security reviews, with skilled testers. That is because penetration testing focuses on real-life consequences.

  1. Maintain trust

A cyber assault or data breach negatively affects the confidence and loyalty of your customers, suppliers and partners. However, if your company is known for its strict and systematic security reviews and penetration tests, you will reassure all your stakeholders.

Interested to learn how we can help? Just let us know!

,

Why every company should get hacked

Did you know that, in traditional western movies, the heroic cowboy wears a white hat, while his enemy wears a black one? That’s where the expression ‘white hat hacking’ comes from. White hat hackers are the good guys. They specialise in penetration testing with the intention of alerting companies to vulnerabilities in their systems, software and networks, to pre-empt hacking attempts by an ill-intentioned individual.

Penetration tests
Penetration tests combine manual and automated methods and technologies. Their objective is to methodically compromise servers, endpoints, web applications, wireless networks, network devices, mobile devices and other potential points of exposure. Once the vulnerabilities have been successfully exploited, the testers use the compromised system to launch further exploits and go deeper and deeper from one vulnerability to the next.

White hat hackers evaluate the ability of organisations to protect their networks, applications, endpoints and users. The hackers use external and internal attempts to by-pass security controls with a view to gain unauthorized access to protected assets. Afterwards, full test results and recommendations are sent to help prioritise remediation efforts. Consequently, the company is in a better position to anticipate emerging security risks and protect its critical systems and most valuable information.

There are two main reasons to hire external penetration testers:

  1. Security breaches and interruptions in the performances of your services or applications can have long-term consequences. In addition to the financial aspect, it has an impact on your business’ reputation, with decreased customer loyalty, negative press, fines and penalties.
  1. Defensive security mechanisms such as user access controls, cryptography and firewalls are useful, but don’t offer a full protection against potential security risks. New vulnerabilities are discovered each day, and attacks become more and more sophisticated. White hat hackers eat, sleep and breathe this, so they are in the best position to show companies where they need to improve their defenses.

Hackers come in different shapes and sizes, and may wear different hats. We only wear white ones. Interested in finding out how we work? Let us know and send us an email.

Create your own Android penetration testing toolbox

Are you a security expert with some experience in mobile pen testing? Then you know that testing Android applications is a real pain in the apps. Mainly because of the various tools and environments needed for mobile penetration testing. All available Android test distributions have flaws, such as missing and/or non-working tools. Luckily, there is a solution to this irritation. Build your own customised mobile testing toolbox, so you have all the tools you need always at hand!

Training

Not sure what steps to follow? Just register for our 1-day training ‘PWN Android Apps with your Custom Built Toolbox’. Our next session will be on November 24th, at the BeNeLux OWASP Day. The course helps you to discover what to do and what issues to focus on, all inspired by our real-life experience.

After this training, you will be able to create, update and manage a robust test environment for Android testing. You will also learn how to use different tools together and what to do if a certain tool doesn’t work. The course focuses on applications running on the device. We’ll also discuss other topics, for example applications attacking other applications and non-HTTP traffic. Moreover, you will get a ready-to-use plan of attack for testing Android applications and some real life examples.

I am a Web Application Security, Mobile Application Security and Software Testing expert at Toreon. I’ll be giving the training together with my colleague Stephanie Vanroelen who focuses on Web Application and Mobile Application Security.

Free

If you are a member of OWASP, you can follow this training for free during the BeNeLux OWASP Day on Thursday 24th November, from 8:30am to 5:30pm at imec-DistriNet at the University of Leuven. There is a limited number of seats available.

Click here to register, or send an email if you can’t make it and would like to discuss other options.

, ,

The youth is out there…

Have you read the research from Kaspersky Lab, on how a lack of guidance for youth results in their temptation to exacerbate cyber-crime instead of preventing it? At Toreon, we didn’t need an extensive and expensive study to realise that youth is the future and that the interest for IT and cybersecurity can’t be sparked young enough. That is why, at the end of the Cyber Security Awareness Month and in collaboration with BruCON, we met up with kids and students to teach them about IT, hacking and cybersecurity.

Hak4Kidz
During the second Hak4Kidz Belgium event, BruCON invited children and youngsters between 7 and 15 for Hak4Kidz Belgium. Six Toreon volunteers assisted in teaching how much fun IT and science are. The event was fully booked in no time.

A few of the things that the children learned:

  • Issues as a fun puzzle waiting to be solved
  • Failure means you get to try again
  • By sharing knowledge, you can focus on solving new problems instead of solving resolved issues over and over again.

slack-for-ios-upload-2 slack-for-ios-upload-1 14917096_10154698227818734_110096449645637643_o 14917084_10154698227018734_4754124548059580092_o 14883569_10154698226353734_5182076026402427068_o14714871_10154698227433734_6605774733114813769_o

Student CTF
During the Student CTF, we took it to the next level. For most CTF’s the gap between the skillsets needed and those taught in school is too large, making it impossible for students to participate. That’s why we created 39 challenges for some hundred students of both specialised and less specialised fields of study, from the University of Ghent and HOWEST. We didn’t expect them to just solve the challenges, but started with introductions on SQL Injection, Traffic analysis, Android reverse engineering and gave lots of tips and tricks.

brucon_ctf3 brucon_ctf

We learned a lot too!
The children and students were not the only ones who learned a lot during these days. We were able to reaffirm how important it is to reach and guide youth in time, but most of all: what an incredible amount of talent is getting ready to enter the real world. The winning team of the Student CTF was even able to solve 36 of the 39 challenges!

What do you think? Did we teach the right things? Would you handle it differently? Or are you interested in a next edition of one of these events? You can let us know in the comments!

,

Want to take your application security to the next level?

When you build an application, are you sure it is safe? Are you certain attackers won’t be able to gain access to private or potentially injurious data? And are you absolutely convinced that an attacker is not able to crash the availability on your system?

Read more