Just a normal morning. Jim, the CTO of a promising start-up, is reading the news. When suddenly one headline draws his attention: A successful security attack on a competitor who’s now struggling to continue his business. At first, Jim grinned with delight but then started to think - what if they attack us? “Of course, we have our IT security officer Bill. But Bill takes most care about the infrastructure. Occasionally, he does penetration tests. But we have weekly deployments,” Jim continued thinking. “So those checks turn out to be overdue too often.”
In many organizations, security departments play second fiddle during the development process. Most companies integrate the agile principles, DevOps, and QA, seeing security too often just as a sticking point to rapidly tap into a market. However, the costs in case of a successful attack can be disastrous. The contrary is true. If security is properly handled from the very beginning of application design, additional costs are marginal.
This story will show you how to efficiently implement a process, which ensures the correct implementation of security standards with little additional costs and at any time.
Let’s see how DevOps becomes DevSecOps.
The first step is to change the mindset, especially at top management, just as Jim did. Typically, for major IT managers, the most significant thing is to deliver top-notch features to beat the competitors and ensure the running of the application. And all these under challenging conditions where the budget is limited, and a timetable is jam-packed.
“How can I ensure security and still meet my goals?” continued Jim contemplating. “What I need is a process. It should just make sure anytime that the application and infrastructure are secure. There shouldn’t be any chance to bypass it, so a quick fix can only spoil it. And it should be so good documented, that the security guy Bill or any other auditors, or customers, or …. are convinced regarding our security activities,” he continued dreaming.
Then Jim remembered that they had similar issues with code quality a couple of years ago. Bugs in production caused many problems, leading to customer dissatisfaction. They solved it by integrating QA in the development process. Automated tests at commit or build time plus a well-documented process for manual testing before delivery.
Why not doing the same to ensure a high-security level?
“This I cannot decide alone, the whole team shall contribute,” he thought. So he invited them for a meeting: Bill, the security officer, Joanne from business, and Igor from development.
“Let’s start from the beginning,” said Bill. "First, we have to understand potential threats. What are the major risks and what they can cause? To begin, all stakeholders should check the importance of data and the effect of particular threats to the business. At this, threat modeling techniques can come in handy:
“If you want that I handle it, please, put it into the backlog,” said Igor the developer.
“Is it as a feature?” asked Joanne.
“No, a threat is more like an anti-feature,” he smiled. “I propose to resort to agile software development methods with all these negative user stories that we could test again and check if we really avoided them on our end.”
A good roadmap is a necessary basis to create a secure infrastructure. As the team was now focussed on the development process, infrastructural aspects like firewalls - despite their importance - were not covered in their discussion.
Bill knew how to handle it. He suggested to develop an architecture for the range of DAST (Dynamic Application Security Testing) technologies. They implied the detection of security vulnerability in an app in its operating state and were useful not only for finding problems in the source code, but those that happened during use as well.
When the plan was somehow elaborated, the time has come for Jim and his team to mention some things that are always good to have on the checklist. Encrypting passwords (at this, passwords should be stored unencrypted in the database, so they cannot be stolen), using SSL connections for communication, and other approaches. All these are well known but too often undeservingly forgotten. Of course, this takes additional development effort, but with the right frameworks and templates, it can be handled.
“We need to make our application more resistant against attacks. Maybe, they can come through the door into the house, but we don’t have to let them go anywhere! Our web applications must check if requests are valid and authenticated. Other checks are about data malformation (for example, a remote procedure call, Session Initiation Protocol [SIP], and so on),” uttered Jim and hotly filled up the last space on the whiteboard.
Everything was clear and unanimous approval was in the air until Igor brought up the topic about the integration of some legacy application.
“No one knows the code,” the team started arguing. “No one knows potential threats!”
Yet, in the end, Joanne came up with an elegant solution.
“Why not moving this application in a special zone with very limited and restricted access from the other applications?
“By doing these, risks are minimized,” the male experts had to agree.
“It is called Runtime Application Self-Protection (RASP),” said Joanne proudly. “This is a security technology that blocks security attacks. Compared to firewalls, which are able only to find threats with the help of network information, RASP is more efficient and can better the security of software through the monitoring of its inputs and blocking of those that could commit attacks.”
Now, they started to talk about the code and looked at Igor the developer. He got blushed.
“Of course I am writing secure code!” Igor said. “But I cannot prove it,” he had to admit.
Igor was getting a little bit unsure. Actually, how does he know it? Of course, he checks passwords strength, and uses encrypted connections to the backend, but, hey, these hackers are really genius nowadays. And what’s about the juniors in his team?
After a while, Igor suggested a simple solution.
“Let’s delegate this job to the computer and do the checks right away. Companies and organizations provide tools that check the code for Static-Code-Analysis-Testing (SAST) while coding.”
And that’s a really good point. As by integrating the static code analysis during development and commit time into the IDE (Integrated Development Environment), you give the developer immediate feedback about the security level of their application. This will dramatically improve their learning curve considering secure coding. Common threats like SQL injections or Cross-Site Scripting were checked.
“What about external software,” Jim asked. “We use a lot of them to speed up development and reduce costs. Unfortunately, they are often the backdoor into the company.”
In this way, it becomes obvious that static code testing needs to check them as well.
“What about the usage of external party software like open source?” suggested Jim. “It significantly reduces development effort.”
“However, at the same time, this code appears very often to be a potential security risk,” replied Igor. “Yet, by checking this code for known vulnerabilities (for example, with OWASP Dependency-Check), you can detect such flaws and fix them, as soon they became known.”
The OWASP utility works by scanning your code and dependent open-source component libraries to see if they contain any key OWASP flaws. It works against a constantly updated database of all known vulnerabilities in open-source software.
“Great job, team!” said Jim proudly. “We understood the potential risks, created an architecture which reduces it, and checked new and legacy code for known vulnerabilities. Did we forget something?”
The team didn’t forget about anything except additional security external vulnerability scanning, what was immediately reminded by Igor and put on the list.
In addition to the white box testing in the development phase, automated security, and vulnerability scanning checks, Jim decided on running similar tests, which simulate the way hackers work. Of course, these tests will be integrated into the deployment process. So it cannot be forgotten. A report will be the proof to management.
“The last but not the least thing to remember is to maintain security on all steps of the app’s lifecycle,” told Jim enthusiastically. And a production phase is not an exception in regard to all mentioned tests. They must be proceeded and carefully monitored. Let’s remember that any incident is to be reported to the architecture specialists and the development team to improve the security level of the application.”
Jim returned pleased to his office. In the end of the day, their new approach is the promising way to deploy to production. No bypasses which might bring in any vulnerabilities were allowed no longer.
“Now, we have a tamper-proof way of our deployment process,” he thought. “In case something happens, we will understand whether we are to blame or no and how we can repair it. Plus, our GDPR officer Helen will also be very excited. Actually, what we are doing is for good reasons required by the new EU law. And I can relax because all activities are properly defined in a clear process. Hackers, now you’re welcomed to enter my house!”