Secure Application Development in a Connected World

Applications are everywhere. Take a look at your mobile device and you will realize how integral applications are to everyday life. We use them to shop, bank, order dinner, get a ride, keep our house warm, even keep track of our children. But such modern conveniences do not come cheap. Our data needs to be shared with applications for them to provide value. In most cases, extremely sensitive information about us and our lives. Who we are, where we live, where our kids go to school, our daily patterns, habits, likes and dislikes. All this data is shared under the assumption and hope that the application creator is doing everything possible to protect our most personal information. As the Facebook/Cambridge Analytica scandal proved, that is hardly the case. Even more disturbing, that information was shared with Facebook’s knowledge. (Read more about Cambridge Analytica here. ) According to the 2018 version of Verizon’s Data Breach Investigations Report (DBIR), applications were the top attack vector when it came to information data breaches, exponentially surpassing common attacks such as backdoors or command and control (C2) vectors, even insider attacks.

Why are Applications a Target?

Most applications need data to provide value. YOUR data.
A recent ZDNet article mentioned “Researchers at security firm Positive Technologies, tested 33 websites and services using its proprietary application inspector and found that banking and financial institutions were “the most vulnerable” to getting hacked.”
Why? Because most applications are horribly insecure and developers do not follow security best practices when developing an application. Applications are designed for functionality, not security. Security is difficult and time-consuming, often adding delays to product launch and revenue generating activities.

Database breaches are easy

Applications store their data in a database in order to efficiently retrieve and make use of it for you. A database may contain everything from configuration data for the application to usernames and passwords, to critical information such as results of your last medical examination.  Some databases know whether you owe anyone money, what you posted on a social media app exactly 2 years ago, what socks you order online and much, much more. Needless to say, this single repository of data is a treasure trove for thieves and therefore is a huge target.
One of the most common database attacks, and interestingly enough, also one of the simplest to protect against, is SQL injection (SQLi).
This is an attack where malicious SQL statements are inserted into an entry field for execution. A successful SQLi attack can read sensitive data such as usernames, passwords, credit card numbers (and more), tamper and destroy data, execute administrative operations,  and worse.
Below is an example of SQL Injection.

This form accepts a username and password as input, validates the entry in a table called users and if both username and password match, grants the user access.
There is no guarantee that a user will only enter a valid username in the username field. In the above example, a user has entered the partial SQL statement ‘ or ‘1’ – ‘1 and a blank password. The SQL engine interprets the command literally and since 1 will ALWAYS equal 1, grants the malicious user access to the application without a valid username or password.

xkcd: Exploits of a Mom

There are many different layers of security that can address SQLi. Independently each can have their flaws. However, layering multiple strategies together can give you comprehensive protection against this type of common attack. In the xkcd cartoon, Bobby’s mother suggests the database input should be sanitized. This should be done regardless, but using sanitization or input escaping does not plug the hole. It’s a myth. This should be coupled with proper database permissions and always use prepared statements or parameterized queries when user input is required. Parameterized queries are the database engine’s natural defense against SQLi. Whitelist Maps are also an effective strategy to protect against SQLi in cases where escaping and parameterization doesn’t help.. If you’re interested in this topic, there are tons of great resources on the www.owasp.org website that describe an overall SQLi protection strategy.

Patch your Applications

POODLE, Heartbleed, Spectre etc are not just cute monikers for security vulnerabilities. They are very real and potentially dangerous holes. When an application vulnerability is identified, it is typically followed by a patch or new version to remediate the vulnerability. And with the proliferation of free and open source software, this activity becomes critically important. Often times, procrastination takes over and the application is not timely patched for a variety of reasons. This now leaves the application wide open to a published, and in most cases, publicized vulnerability.

Security in your Application Development Lifecycle

People often ask me how to change the mentality within their development organization to be more security focused. My standard response is “security cannot be left for the end”. Introduce security into your development processes early and re-introduce them often.  Education and reinforcement is key.

I’ve listed a quick rundown of how security should fit into each phase of your software development cycle.

The Requirements and Design Phase

Ask the right questions early to avoid pitfalls that become very expensive to fix, post-production.

• What type of information will my application process?
• What does my data flow look like?
• What are the potential exposure points of the data?
• What standards need to be accounted for?
• Password policies, legal and regulatory compliance requirements, encryption levels
• Security Architecture
• Web Server, database, middleware, interfaces with other systems, operating system
• Involve your security/compliance/risk groups at this stage to avoid surprises and conflicts

Development and Testing Phase

• Ensure security controls around your source code
• Use Secure coding standards
  • Code reviews, Code Reviews, Code Reviews – oh…didI mention CODE REVIEWS?
  • Automated code quality scanning tools
  • Unit testing of security features
• Security awareness training for developers and testers
• Application Testing
  • Ensure application meets requirements and standards set in the design stage
  • Static and Dynamic Code Analysis
  • Penetration Testing
• Security sign-off before deployment

Production Release

Just because you’ve launched your application and celebrated the big release with a party doesn’t mean your work is done. In fact, congratulations, you got past the easiest stage. Now the real security work starts.

• Ensure you have security configured at every layer of the application stack of every layer
  • Access control
  • Lock down your Operating system and Platform
  • Deploy a Web Application Firewall (WAF)
• Ensure application files are not modified
  • File and System Integrity monitoring
• Continuously monitor to detect anomalies
  • Alert quickly
• Create an incident response plan to deal with threats
  • Don’t wait until an incident happens to react
• Preserve forensic data
  • Logs, audits
• Review for suspicious behavior

 

But Steve, What about Agile Development?

Agile is a software development approach where requirements and development evolve through an iterative collaboration effort rather than planning the deliverables and keeping to the fixed plan. Since traditional planning processes don’t always fit into this strategy and security is viewed as a Non-Functional Requirement, finding the right stage to introduce security into an Agile SDLC can be a challenge. But this is not impossible. A lot of companies have successfully integrated security in their agile development process. Netflix, Etsy, and Amazon to name a few. The key is to ensure your developers are empowered with knowledge and an understanding of the needs and tools required for secure software development. Security Awareness.

While we can go much deeper on this topic, I’ve covered the basics of what application developers and others responsible for the application and its data should be aware.  Another great resource is the owasp.org website. Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit organization focused on improving the security of software. If you need help securely setting up your development environment or simply want a review to ensure everything is working as expected, please feel reach to reach out to us at www.xypro.com

“The cost of removing an application security vulnerability during the
design/development phase ranges from 30-60 times less than if removed during production.”
Gartner, IBM and The National Institute of Standards and Technology

Steve Tcherchian, CISSP
CISO and Director of Product
XYPRO Technology
www.xypro.com
@SteveTcherchian
@XYPROTechnology