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:
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.
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.
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.
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:
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.
I would highlight some areas to be aware of to improve your security while planning, designing, developing/testing and deploying/maintaining the application.
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:
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.
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.
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.
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.
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.
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
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.
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 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.
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.
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
As we are becoming a more connected society, the need for internet access on the go is becoming more important. Many people would look for a public Wi-Fi access when they are out and about. In May 2016, Symantec (a leading cybersecurity firm) conducted an online survey of 1025 people to find out what users are doing on public Wi-Fi.
From the report, 57% of consumers think their information is safe when using public Wi-Fi connections. And only 49% think that they are responsible for securing their own information. 18% believe that the Wi-Fi provider is responsible for protecting their data and another 18% believe it is the website operators who are responsible.
Common activities on public Wi-Fi include logging into a personal email account (55%), logging into social media (54%) sharing photos and videos (38%) and 20% have used it to access their banks or perform some financial transactions.
But behind some of these “free” Wi-Fi access lurks some malicious intent. This paper will cover some of the basic hygiene you should adopt when using public Wi-Fi connections.
Many people are using free Wi-Fi access without a second thought about the security of the connection. Most would trade privacy or security for convenience and are not fully aware of the consequence. The biggest threat would be that your data, traffic and identity could be stolen and majority of users are not doing enough to protect themselves.
With the lax protection in most public Wi-Fi, many users are putting their data and devices at risk. Encryption is usually employed to keep network traffic private and prevent snooping. For example, the Wi-Fi network at home is usually set up with some encryption like WPA2, so that even if your neighbour at home is within range of your Wi-Fi network, they cannot see the web pages you are viewing. This wireless traffic is encrypted between your device and your wireless router or access point.
When you connect to an open Wi-Fi network like one at a shopping centre, restaurant or airport, the network is usually unencrypted. This is usually indicated by the lack of a padlock symbol (next to the network name on your device or you do not have to enter any password when connecting to the network. Your unencrypted network traffic is then clearly visible to everyone in range. Even with a secure banking application with the data encrypted, they may be able to know which bank you use.
There are also many rogue access points that are mimicking a legitimate Wi-Fi connection to fool you into connecting to them. The biggest threat with this is the ability for the hacker to position himself between you and the connection point. So instead of connecting directly to the Wi-Fi hotspot, information will be sent to the hacker, who then relays it on.
Hackers can also use an unsecured Wi-Fi connection to distribute malware. If you allow file-sharing across a network, the hacker can easily plant infected software on your computer. Some ingenious hackers have even managed to hack the connection point itself, causing a pop-up window to appear during the connection process offering an upgrade to a piece of popular software. Clicking the window installs the malware.
I would highlight some areas to be aware of to improve your security while looking for and connecting to public Wi-Fi hotspots.
Be careful of fake (rogue) Wi-Fi hotspots
There are many hackers out there that use a fake (honeypot) Wi-Fi hotspot to collect information about the user. These rogue Wi-Fi hotspots often use the same SSID as legitimate hotspots (e.g. Wireless@SG, etc.) or use a name associated with the location (e.g. yourlocalcoffeeshopfreewifi, etc.)
These rogue Wi-Fi hotspots often attempt to capture your credentials with a spoofed login screen and often would just collect the information and pass the traffic straight to the internet so users may not realize the webpage was a fake. This is especially hard to detect in a foreign hotel.
Figure 1: Fake Hotel Login Screen
The other use of these rogue Wi-Fi hotspots is to infect your device with a malicious malware in the form of an update program or a fake “Terms of Service” link that will download and execute a malware.
At minimum, make sure your device is protected by the latest anti-virus or other end point protection software.
Be careful of Wi-Fi hotspots that ask for your phone number
There are some Wi-Fi hotspots around the world that ask for your phone number and then send you an SMS with the access code. These kind of hotspots can be used to conduct targeted attacks on the user.
Here is a possible scenario that might be played:
1. User connects to a rogue hotspot and enters the phone number.
2. User continues to use the connection to perform a few actions (check email, check bank balance, etc.)
3. Although the mail or banking app is secure, the hacker can still see who you are connecting to, therefore will know which email service you use or which bank you use.
4. Hack sends a spoof SMS which can carry a malicious link that might inject a malware or send you to a fake website.
Figure 2: Fake SMS
Choose an encrypted hotspot over an open hotspot
This is true especially at airports, some airline lounges offer encrypted Wi-Fi hotspots (those that need a password to join the network). These networks are preferred over the typically free airport wide hotspots. But do pay attention that it is not a rogue Wi-Fi hotspot.
Use of VPN
Virtual Private Networks (VPN) is a private tunnel that encrypts the traffic between end-points. The use of a VPN service will help secure your traffic from eavesdropping but do note that the VPN used should be of a reputable source. I recommend you do some research on the VPN vendor before signing up for any service. An alternative is to host your own VPN service, which is an extension from my previous paper “Protection of Home Networks”.
However, do note that even with the use of a VPN to encrypt the traffic, there is still a vulnerability – this occurs at point of connection. The VPN cannot connect until you are connected to the Internet, and the VPN connection is not instantaneous. Sometimes before you can connect to the Internet, the Wi-Fi Hotspot will direct you to a captive portal to manually accept some “Terms of Service” agreement.
During this period before your VPN connection is established, your device might be trying to connect to some services. For example, you could have an email client or chat service that tries to connect automatically, and this traffic is out in the clear for all to see, including potentially the login credentials.
Even if your software attempts to use HTTPS, it could be vulnerable to attacks like SSLStrip, which tricks the software into using open HTTP anyway. This vulnerability window might be very small, but that is enough to expose valuable information like login credentials.
Configure software firewall
If you are using a public Wi-Fi from your computer, there are a few more protection actions you could employ.
The idea is to block all inbound and outbound connections on your public networks (or zones) with the exception of a browser that you use to connect to captive portals. That browser should be one you only use for this purpose.
You should also set up a profile/zone for VPN traffic where inbound / outbound traffic is less restricted (you should always block all outbound connections by default and then allow connections as needed) This approach will ensure your email and other programs do not send unnecessary data out before the VPN is connected.
Although there might be a need to get connected on the go, it pays to be vigilant on who you are connecting to, how you are connected and what you are doing online over that connection.
Paying attention to basic security hygiene can save you from a lot of trouble later.
A link to a PDF version of this blog can be found here
Some folks have asked me about some of the more affordable UTM devices they can get.
Today some of the more affordable UTMs are :
- Sophos SG series
- Dell SonicWall TZ Series
- Zyxel USG series
the Sophos devices have the highest throughput but a bit more pricey.
The lower end sonic wall (TZ SOHO) is the cheapest but also lowest bandwidth, I actually recommend the TZ300w as a minimum level for SonicWall.
My personal favourite is the Zyxel USG60w, although the USG40w could fit most needs.
at the end of the day, it would be a decision to balance cost vs performance.