So when you need a design firm to help with secure software for your next device, NeuronicWorks has over a decade of experience building secure software across multiple industries, including wearables, medical, automotive, and transportation, to name just a few. Be in touch today to find out how NeuronicWorks can help you design your most secure software—all from the outset.
Minimizing Software Attacks
Welcome to the third and final article in our ‘Designing Secure Devices’ series. This time, we’re looking at software—its vulnerabilities and some best practices to design more secure software from the outset. Be sure to check out the other articles in this series on designing secure hardware and designing secure firmware.
Designing secure software is more crucial now than ever. Today’s primary threat to businesses is cyberattacks, and secure software is a frontline defense against these hacks. Already, 59% of companies have experienced malicious code and botnet attacks, and 51% have experienced denial of service attacks. With an average cost of each attack calculated at $3.9 million for small and medium-sized businesses and a staggering $116 million for publicly-traded firms, successful cyberattacks can be crippling for most companies, if not fatal.
With the ever-growing importance of connectivity in our lives—consider that the burgeoning Internet of Things (IoT) market is 31 billion connected devices this year with projections that we will have 75 billion by 2025—the necessity for designing secure software from the outset has never been more urgent.
Types of Attacks and Risks
The first step in designing secure software is understanding the kinds of attacks that software is subjected to. Here are four of the most common attacks that your software should be prepared to face.
1) SQL Injection Attack: a structured query language (SQL) attack uses malicious code to get servers storing critical data for websites and services to divulge information. This is especially dangerous if the server stores private information such as credit card numbers, user credentials, or any other personally identifiable information.
2) Cross-Site Scripting: an attacker inserts a malicious code in the user’s browser once the latter visits the attacked website. It goes after the visitor directly (instead of the website), to steal personal information.
3) Denial-of-Service (DoS): the attacker overloads the website/network with an overwhelming amount of traffic, more than what the website/network can handle. As a result, the service becomes unavailable to end-users.
4) Session Hijacking and Man-in-the-Middle Attacks: the attacker will hijack the session (the process that happens between the computer and remote server while logging into a website) by capturing the session ID and making a request, as if they were the computer, to gain access to confidential and unauthorized information on the webserver. Man-in-the-middle attacks happen when the attacker inserts themselves between the remote server and the computer and pretends to be the other party so they can access information from both sides.
Best Practices to Design Protected Software
1. Implement Strict Password Security
It will likely come as no surprise to anyone that some of the most straightforward vulnerabilities to attack your application are due to not enforcing stricter password rules. If there was ever a time when you could get away with a password that was “password123”, those days are long gone now.
According to a recent University of Maryland study, a device with Internet access is attacked somewhere every 39 seconds on average, with unsecure usernames and passwords giving hackers the greatest chance of success. Most such attacks are run with relatively unsophisticated “dictionary scripts” that simply run through lists of common usernames and passwords until they find a combination that works. The study found that in 43% of these password-guessing attempts, the hacker gained access by simply re-entering the username in the password field.
2. Create an Application User
Other times, developers overlook the small things. It’s not always about encryption and certificates. Sometimes a database’s user permissions are too open, creating vulnerability and a vector for attack. Applications are only as open as you allow, and it’s usually a good idea to create an application user who has only limited access to specific data.
Backing up data regularly can also help prevent loss in any circumstances, whether that’s a bad actor trying to interfere with your software or your own developers making a mistake.
3. Sanitize Inputs
As for the specific forms of attacks cited earlier, there are many ways to prevent SQL injection, which is the act of using SQL syntax in an input on your website/web app to obliterate your data completely.
When you have any places the user can enter data; web developers aren’t the only ones on the hook, this goes for you too mobile app developers, you must do what is called ‘sanitizing inputs.’ This prevents SQL statements like “ ’); DROP TABLE users; ”. That way, if a user enters this destructive request into your app you are safe. Malicious actors can also use SQL injection to determine the structure of your database (schema) and even get other users’ personal information.
Cross-site scripting is most commonly used on sites like forums or blogs that allow users to post content, such as comments or questions. It doesn't take much with modern browsers to find out all the information about how your website is constructed.
For example, if your website uses JavaScript or other forms of it, like Jquery, anyone can discover this simply by using the ‘inspect element’ feature of their browser. Hackers can then make a post with a link to a legitimate website but with their own code as part of the URL so that when it runs it sends information to the hacker. Again, this can be prevented by sanitizing inputs.
4. Implement Load Balancers and IP Banning
Direct denial of service has less to do with application security and more to do with the service infrastructure where your application is running. If your application is running on a single server and you don’t get a lot of traffic to your services, or your application has a small overhead when processing requests you may not think you are at risk. This kind of thinking can cause you to not consider things like load balancers. A load balancer does what the name suggests. Here’s an example of an application architecture with a load balancer. An E-commerce site could have lots of traffic sporadically throughout a weeks’ time. Request numbers anywhere from 100 to 5000 visitors depending on popularity. If a marketing campaign like “Black Friday Deals” brings in more users and requests to your application your server will be receiving more concurrent requests than it can handle and you can get DDoS’ed just like that. So instead you have two servers with separate databases or a shared database running your application with a load balancer. The load balancer takes the requests to your application and hands them off to whichever server has less traffic balancing the traffic between the two servers.
Another useful tool to curb the number of requests coming in is to have a service for IP banning. Usually DDoS attacks come from one or a small handful of IPS. If the IP traffic is making too many requests per second you can reasonable assume that is a DDoS attack and the service can ban traffic from that IP so that the IP is blacklisted from reaching you. So instead of your application going down you deny the attacker from even trying to reach your application. Apart from security it is always a good idea to keep application scalability in mind as well which is another practical use of a load balancer. Many cloud providers have useful tools for setting these up, including the ability to set alarms that trigger when conditions you declare are met.
5. Use Secure Website Connections
Man-in-the-middle attacks are preventable using secure website connections and other methods like authorization keys that have short life spans.
Think of a key that is valid for just 30 seconds when using a credit card at an online store. The web store makes the request to the service provider and authenticates the card with them. If any man-in-the-middle attempt to spoof the service that is responsible for taking the money with another one they’ve created with the intent to steal money is made, by the time the interference has happened the key is expired and the request will fail, thus protecting the card and the transaction.
6. Security from the Outset
Many security risks can come from improper or loose configuration of access permissions. Maybe you’ve left the firewall settings open on your server. Perhaps you’re using old versions of operating systems, applications, or packages with known and exploitable vulnerabilities. Or maybe you’re not forcing open facing public users to have a stronger password.
These kinds of considerations are top priority at NeuronicWorks when we develop software with and for our clients. You can see from the other two articles in this series—designing secure hardware and designing secure firmware—that we look at projects from every angle, whether designing hardware, firmware, software, or a combination of all three.
All Blogs