5 Reasons Why App Sec and Eng Teams Must Work Together

The popularity of cloud-based computing has made API security the next big challenge for software engineers. APIs, or Application Programming Interfaces, will soon be the primary target of cyber attackers.

Data and software shared over the internet are subject to attacks that may steal personal information, impact the safety of IoT devices, hijack software and systems for ransom, and utilize servers for unauthorized criminal activity.

Hackers are becoming more creative, and the strategies to protect against them are becoming more complicated. Security must be implemented at the code level during API development, but this places a burden on software engineers. It can delay production and prevent the implementation of desired features.

Designing for security can make it difficult for software engineers to be productive. Software engineers need help.

Size of the Problem

APIs Aren't Just For Smartphone Apps

The ProgrammableWeb directory lists more than 23,000 publicly accessible APIs, and API traffic accounts for 83% of all internet traffic.

The idea of the modern REST API originated in 2000 when Roy Fielding described it in his Ph.D. dissertation at the University of California - Irvine, Architectural Styles and the Design of Network-based Software Architectures.

REST APIs later entered the scene that same year, being used by Salesforce and eBay in 2000, and Amazon Web Services in 2002. They started gaining popularity when Flickr launched its API in 2004, when Google launched its Google Maps API in 2005, and when Facebook and Twitter launched their APIs in 2006. These APIs were released to the public, allowing developers to write apps that could access these platforms.

APIs have been developed for banking and investing, e-commerce, mapping and navigation, autonomous vehicle control, vehicle traffic routing, and many other uses. They offer valuable data, including personal financial information, financial transactions, safety data, mapping, and geolocation.

What Can You Lose When it Happens To You?

Hackers aren’t just disgruntled pimple-faced teenagers sitting at home on a Friday night. Cyber crime has become organized, and today’s “hackers” are sophisticated organizations, even including some nation-states. Some insurance companies have tried to classify cyber crimes as acts-of-war, and some have encouraged their clients to pay ransoms in ransomware attacks.

In just the first quarter of 2020, there have already been 1,196 reported data breaches, resulting in a theft of 8.4 Billion data records. The total worldwide cost of cybercrime is forecast to hit $6 Trillion per year by 2021, and the global expense in defending against these attacks is projected to reach $134 Billion per year by 2022.

If it happens to you, your costs could reach as much as $13 million per year. (This is the 2018 average for the annual cost faced by each victim of cyber crimes). The expenses you may face are a combination of information loss, business disruption, revenue loss, and equipment damage.

And here is something else to consider. Information loss, which is already the highest cost attributed to cyber crime, could see significant increases in the near future, when regulators begin imposing fines for GDPR and CCPA violations.

API attacks come from multiple directions. Once the attackers find you, the attacks will continue, possibly numbering in the 1000s of attacks per day. And it is not just the number of attacks that matters. Hackers will use several types of attacks against you.

Some of the attacks will be a combination of the above attack types. For example, a botnet attack often works in conjunction with a malware attack.

A botnet is a large group of computers and IoT devices that have been infected by malware. Once infected, these devices launch coordinated attacks against other targets, including APIs. Botnet attacks are especially difficult to prevent and detect because they come from many different locations.

The profit and ease of committing cyber crimes means that these attacks will only continue to get worse.

5 Reasons Security and Software Engineers Must Work Together

Reason 1: Security and Software Engineers Must Collaborate to Manage Conflicting Objectives

Security and software engineers have conflicting objectives. Software engineers enable users to do something. Security engineers prevent attackers from doing something.

Software engineers strive to add new, exciting features to their products, and they need to complete their products swiftly and on-schedule. They may view security as an imposition, as it restricts the features they can add, increasing the time to develop a product.

But to be fair, both groups are engineers, solving complex engineering problems. Software engineers usually have a bachelor's or master’s degree in computer programming. Security engineers typically have a master's degree in security engineering. While software engineers focus on product development, security engineers focus on understanding how cyber attackers exploit products.

Today's hackers are very sophisticated, and APIs are very appealing targets because they provide access to a wide range of the data held on a server. APIs can be protected using firewalls, VPNs, HTTPS, and encryption, but they also need code-level protection, implemented directly into the design.

Protecting APIs at the code-level can only be accomplished when security engineers and software engineers work together, developing strategies and making compromises that give the best tradeoff between features and protection.

Reason 2: Security Engineers Can Help Software Engineers Stay Abreast of New Attack Strategies

API developers need to guard against an ever-growing, ever-changing list of cyberattacks. Keeping track of these is time-consuming and complicated, so it is preferable to have security engineers follow these rather than burdening your software engineers with it.

The top 10 security risks are listed in the OWASP API Security Top-10. This list is published and updated regularly by the Open Web Application Security Project, a nonprofit foundation that works to improve software security.

The OWASP API Security Top-10 for 2019 includes the following vulnerabilities:

• Broken Object Level Authorization: Allows attackers to access restricted or unauthorized data
• Broken User Authentication: Allows attackers to utilize another user’s credentials by spoofing user authentication tokens
• Excessive Data Exposure: Some APIs return all of an object's properties, rather than just the ones needed by the requesting app. Attackers can exploit these additional properties.
• Lack of Resources & Rate Limiting: Attackers send excessively large HTTP requests to an API that overload the server, reducing performance and generating Denial of Service (DoS) errors. Even more confusing, a DoS attack may come from an army of devices working together, rather than from a single source.
• Broken Function Level Authorization: Allows an attacker to gain access to higher privileges, such as administrator privileges
• Mass Assignment: Allows attacker to modify or create new object properties, such as changing a user's role to "administrator"
• Security Misconfiguration: Software engineers may use relaxed security configurations during the development phases (for example, not requiring authorization checks or encryption) and then forget to remove these configuration options in the released product.
• Injection: Attackers can sometimes insert SQL or other commands into object properties. For example, they might replace a username with a SQL command.
• Improper Assets Management: When APIs are updated, care must be taken to remove older API versions from servers because attackers might still access these older versions to bypass patches in newer versions.
• Insufficient Logging & Monitoring: Swift and efficient breach detection requires keeping detailed log files and using software that automatically monitors these files and issues alerts as soon as they detect suspicious activity.

Your security engineers can help your software engineers understand these vulnerabilities and can also alert them of new vulnerabilities as they are discovered. The teams can then work together to develop security strategies that protect your API without limiting performance and increasing the time required to create new APIs.

Reason 3: Security Engineers Can Help Manage Tradeoffs With Business Groups

No security is perfect, and some protection strategies are not worth the cost required to implement them.

Business units expect some losses due to theft. If the amount lost is small (say, 5%) compared to revenues, they may decide that it is an "acceptable" loss. With this mindset, they may encourage design teams to forgo API security to add desirable features and meet aggressive development schedules. 52% of companies forfeit cybersecurity to meet deadlines or design objectives, and designers complain that CEOs push back on security measures that take extra time to implement.

However, cyber attacks also have intangible costs, such as the impact a breach can have on a company's reputation. Security engineers can help business teams understand these intangible losses. They can work with these teams to identify the best security tradeoffs, relieving software engineers from being involved in these arguments.

Reason 4: Software Engineers Can Help Security Engineers Detect Attacks Sooner

It can take more than 200 days to detect a security breach. During this time, attackers may be exploiting financial data, modifying or destroying data on your server, or using your servers to mask their criminal operations.

Detecting attacks sooner requires maintaining API documentation and strict management of the API assets. Software engineers need to maintain these specifications, update them and make them available to the security engineers. In addition, continuous run-time monitoring of the ongoing API activity is key.  The software that monitors these activities should automatically generate alerts whenever it detects suspicious activity.

Software engineers can define abnormal usage patterns (such as repeated attempts to guess a password) and add features that help detect these attacks. Incorporating monitoring into an API’s design can help security engineers by flagging possible attacks sooner, with fewer false positives.

Reason 5: Collaboration Can Create a "Secure by Design" Development Environment

Iterative design methodologies like DevOps, DevSecOps, and Agile enable companies to release APIs quickly by getting early versions to customers as soon as possible and then sending incremental updates, rather than following long development cycles. But if done incorrectly, this can make API security even more critical while also making it easier to overlook.

In the long run, implementing cybercrime protection at the code-level and secure coding practices are lower cost, more efficient, and more effective than trying to patch security holes in a finished API. The entire development environment, especially the tools that are used for coding and testing, should be structured to encourage and enforce security protocols.

Security engineers and software engineers, working together, can build a "Secure by Design" environment by finding and using tools that search for and prevent security vulnerabilities. Tools are available that trace end-to-end performance and use advanced analytics to make your APIs more secure before releasing them to your customers. These tools can:

• Uncover unanticipated user behavior
• Find abnormal app and API behavior
• Store and predict malicious attack strategies

Communication: The Key to Collaboration

API security is a moving target (you’re the target) and the cost is immense if you get hit. Hackers won’t allow you to be lazy by using a static defense strategy. Your strategy must be dynamic and your defenses must be constantly evolving.

To start working together effectively, security and software engineers should meet regularly to determine what problems they face and what solutions are possible.

Discussions can begin by identifying conflicts:

• “What are the conflicts between design objectives and security objectives?”
• “What are the conflicts between business goals and security objectives?”

Continue by assessing what you are currently doing about security:

• “What risks are our defenses already covering?”
• “What threat vectors are applicable to our environment?”
• “Do our current defenses against these risks need to be improved?”
• “What risks are we overlooking?”
• “Do we need to begin defending against these additional risks?”

Evaluate your environment and procedures:

• “Do we need to add security-centric design and/or test tools?”
• “Do we need to add security to our standard design procedures or design specs?”
• “Do we need to incorporate security (‘ethical hacking’) into our testing procedures?”
• “Do we need to improve our sign-off procedures?”
• “Do we need tools to identify and communicate the root-cause of the issues to the developers?”

Cybercrime is on the rise and will only continue to worsen, and APIs will soon be the primary target of hackers. Defending APIs against cyber attacks requires incorporating barriers directly into the API code. But this must be done in a manner that does not limit features or performance.

Security engineers and software engineers can help each other recognize, create, and implement the best strategies to protect APIs while still keeping them competitive and responsive to their customers’ needs. Collaboration is the best way to incorporate a “Secure by Design” philosophy into your API products.

About the Author

Tim Schreyer is a technology writer and regular contributor to The Inside Trace.