.. Ian Loe - Blog

From EDR to MDR

Was recently featured in Enterprise Security Magazine on the topic of moving from EDR to MDR. As we are hit with the ever increasing volume of incidents and the shortage of trained professionals to handle them, we need to leverage partnerships to deal with these issues. One of the ways I am addressing this, is to make use of Managed Detection & Response services with a vendor to help react faster and gives us time to mitigate the issues.

Here is a link to the article : https://managed-security-services-apac.enterprisesecuritymag.com/cxoinsight/from-edr-to-mdr-the-security-industry-gets-serious-about-visibility-nid-1480-cid-83.html

And here is a copy of the article in PDF -> click here to download
Comments

New YouTube Channel

Do check out my youtube channel where I talk about some of the latest threat in 2019, diversity in hiring and a brief history of the SOC.

https://www.youtube.com/channel/UCJV1knD4fKXm6aXd7Ip2O4g
Comments

Kicking off 2018 with New Classes

2018 Let's kick start with some new classes!

I will be kicking off the 1st in a series of classes around security architecture.

Today is the official launch of the SUTD Academy and I am happy to be the 1st new class launched this year!

here is a link to the class -> https://sutd.edu.sg/Education/Academy/Our-Offerings/SkillsFuture-Series-Courses/Cybersecurity/Cybersecurity-Architecture-Fundamentals

This would be an introduction level class covering approach to security, threat modelling, misuse cases, and how to document architecture decisions.

I would also cover the inks between good architecture and the ability to support operations like the various incident response frameworks which might be adopted by various organisations.


Pasted Graphic 12


Too often vendor who are only engaged to build a solution fail to take the operational aspects of a system into consideration when designing the system.

With my experiences in running operations, I hope to help raise the awareness of architecture impact to operations.

So if you are interested and in Singapore, please do register for the class!



Comments

Security Architecture

Observations

Over the last few years I have seen many security professionals split into 2 main categories:

  1. Product specialist

  2. Security operations (at fixed levels)


I do feel that there are far too few folks moving to security architecture. I am not sure if it is because of a lack of opportunity or interest.

For those who are interested and are looking to venture into this space, I am trying to create a class and (hopefully) write a book on this topic.

I think the security space need more people with deeper background in system architecture and engineering, of coz we will always need specific specialist like the crypto guy but in general we need more people who can relate to our colleagues in infrastructure, development and especially operations.

I will be starting a series of class at the SUTD Academy in Singapore on the "Fundamentals of Cybersecurity Architecture" where I hope to get more folks interested in pursuing this as a career aspiration.

the course will cover architecture considerations across all phases of a system lifecycle from requirements and build to operations and decommission.

The short 2 day introduction class is not to make anyone an architect but to introduce the discipline of security architecture to a wider audience, to demystify the role and to spark more interest in the topic.


Here is the agenda of the class :

agenda

Hope to see more people taking this up!

Comments

Secure Software Development

Introduction

Cyberattacks surfaces can be classified into 4 main areas: public spaces, private networks (home), organizations’ network, partner networks. This is illustrated by GRA Quantum with their infographics below:

Pasted Graphic

Figure 1: Cyber attacks surfaces


As part of my series of papers to cover the cyberattack surfaces, I have covered public and private spaces (home networks) with my papers “Public Wi-Fi Hygiene: Things to Consider” and “Protection of Home Networks: A Suggested Approach” respectively. Now I shall cover a part of the organization’s network pertaining to application security.

As cyber criminals’ skills evolve and with network security maturing, cyber attacks are increasing moving to application level hacking. According to The Solutionary Security Engineering Research Team (SERT) Quarterly Threat Report for Q2 2016, web application attacks, malware and application specific attacks comprised approximately 62 percent of all attacks during the second quarter of 2016. A chart from the report can seen in figure 2 below.

Pasted Graphic 1

Figure 2: SERT summary of attacks for Q2 2106


There is clearly a need to improve the security posture of all applications before they are placed in production.

Background

Over the years, security has generally been focused on network perimeter security with reference architecture clearly mandating the deployment of network firewalls, intrusion detection and prevention systems, etc., but with the rise in application level attacks, it is clear that traditional network security solutions cannot adequately protect against application attacks.

While firewalls and intrusion prevention systems (IPSs) are essential for preventing network
attacks, “next generation” firewalls go one step further by adding application awareness, which compares traffic against fingerprints of known applications. Unfortunately, none of these products understand acceptable user behavior in the applications, such as the field input length found in interactive screens, and allowed characters. Without this application understanding, network security products cannot accurately detect application attacks like SQL injection, XSS, CSRF, and parameter tampering.


Although Web Application Firewalls (WAF) play an important part in blocking off some of these attacks, there is a limit to externalizing the protection of applications.
Problem Statement

To improve the security posture of applications, security needs to be baked into the design from the beginning and not as an afterthought. There is a need to apply design thinking to security too. Most application teams use design thinking techniques to see things from the users’ perspective, but I argue that we also need to apply these same techniques to how a hacker would think.

Security needs to be applied in every stage of the software development lifecycle to improve security in every aspect from requirements to operations.

There are a handful of secure SDLC frameworks proposed by multiple parties, these are some of the more prominent ones today:

Pasted Graphic 2

Figure 3: Secure SDLC frameworks


l shall not go into the details of each framework or suggest which framework to adopt, but will go through some of the key considerations when putting in place a Secure SDLC methodology in the organization.

Considerations

I would highlight some areas to be aware of to improve your security while planning, designing, developing/testing and deploying/maintaining the application.

Planning


During the planning phase, it is important to design security into the application. You should also be doing some form of threat modelling here.



Start with security in requirements (Abuse case)


Typically, in planning phase, requirements are gathered in the form of use cases. These use cases need to be supplemented with abuse cases. The concept of abuse cases is not new, it was developed in 1999, but is not often used. An example of abuse case for a university system is show in the figure below:

Pasted Graphic 3

Figure 4: Abuse Case example in UML

It is important to start thinking about exploits so you can bake the defence into the product. I would highly recommend including a security professional or white hat hacker to be part of the planning stage as it “takes a crook to catch a crook” and most application designers are not used to thinking in terms of exploits.

Risk in business processes


As we adopt a risk-based approach to security, we need to look at how risk is injected into process flows and what are the risk-mitigation measures to put in place. These can be technology based measures or simply process based measures. An example of a normal and imperilled business process flow can be seen in the figure below.

Pasted Graphic 4

Figure 5: Normal vs imperilled process flow

Understanding the risk at each process steps early, can help strengthen the process flow and overall security posture of the application.

Designing

During the design phase, we will be looking into the architecture of the solution. These should include the enterprise security architecture as well as application specific security architectures.

Enterprise security architecture

An enterprise security architecture helps tie up multiple applications together by creating solid foundational components and subsystems that are used across all applications. These should include security audit, flow control, access control, trusted credentials and integrity subsystems. A sample enterprise security architecture block diagram is shown in the figure below.

Pasted Graphic 5

Figure 6: Sample Enterprise Security Architecture


These subsystems can be further expanded to components and processes that must be managed. An example of the credential subsystem process is shown in the figure below.

Pasted Graphic 6

Figure 7: Sample credential subsystem processes

User experience design

Security should not be separate from design. Many instances of data breaches are a result of human error. Many of these can be avoided by knowing who your users are, and how they would be using the applications. One key design principle to remember is never leave users guessing what they should be doing or how to use the application. Using microinteractions is a very good thing in security design, for example in changing passwords, etc.


Developing/Testing


I have grouped developing and testing into a single group for discussion as I believe they are tightly integrated. Development is moving to a continuous integration cycle and testing is an integral part of this cycle.

Secure coding practice


There are many articles and books written on good secure coding practises so I shall not go into details here, but these practices are important habits for the development team to adopt.

Some of the principles of secure coding practices are to validate all inputs, keep it simple, default deny to all access, pay attention to compiler warnings, etc.

It would be good to do a refresher once in a while for the development team to reinforce the habits and to introduce new employees to adopt them.

Peer review is also encouraged for highly sensitive applications to further reduce the risk of vulnerabilities creeping in. As this can be an expensive process, users should adopt this at their discretion based on the risk rating.

Static code scanning


At a minimum, source code scanning should be performed with automated build processes. This is probably more suitable for traditional languages like .Net languages, Java, C, C++, etc. Due to the nature and structure of the language, today there is limited ability to do this for JavaScript based applications or frameworks like AngularJS etc. But as technology improves, there are ways to use machine learning to help identify patterns in these codes. They may not be as robust in capturing all the details like you can with traditional languages and tools, but it does offer some help to identify the more common vulnerabilities.

Dynamic code scanning


Before deploying an application, it is usually necessary to perform a dynamic code scan. A dynamic code scan can help discover vulnerabilities in a run-time environment which might be missed by static scanning.

Deploying/Maintaining

Before going live or with any updates, it is recommended that dynamic scans be run and in addition, there are some other actions that are necessary to further enhance the security of the application.


Penetration testing


Penetration tests should be employed to discover if any vulnerabilities can be exploited to gain access to the system or data. As penetration testing is an established and mature discipline, I shall not go much deeper into this.


Environment vulnerability scanning


Beyond the boundaries of the application, it is important to understand the environment in which the application is deployed. The operating systems it runs on, the application server it is deployed to, the database where the application data is stored, the transport mechanism used, the message payload protocols, etc. are all areas that needs to be examined for vulnerabilities and needs to be patched or harden accordingly.

Container scanning


With the popularity of container technologies like docker, it is also important to perform image comparison and vulnerability scanning of the container. There are freeware tools such as DockerScan available on GitHub and these should be employed if possible.

Containers should also be configured to only have the minimum required components to run the application to reduce the attack surface.

Security Operations (SecOps)


I would also like to add a section on Security Operations which covers a wider spectrum of the Secure SDLC cycle.

Security operations is the marriage of IT security and operations in the way DevOps is the marriage of development and operations. An example of SecOps practices is “Continuous Security Testing” , which is similar in concept to continuous integration found in Devops practices. Just as DevOps break down development silos in the development and operations process, SecOps does the same to break down security silos to allow a better integration approach.

Adopting SecOps practices would also reduce human errors by automating many of the security testing task that used to be handled manually.

A team adopting SecOps practices would also be able to have better monitoring and controls by integrating better with Security Operations Centres (SOCs) and enable better threat prediction and remediation.

This is a much bigger topic which would be covered in more details in a future paper.

Conclusion


This paper is not a prescriptive approach to secure software development but serves as a piece to encourage better practices that can be adopted in software development to improve the overall security posture of an organization.

There are a lot of developing areas in secure software development and I encourage you to find practices and tools you can adapt to your development and to bake these into your SDLC or DevOps cycles.

Security is everyone’s business, we can all make this world a safer place.

PDF version of this blog can be found here


Comments

Ian's Blog