App Security — The painful invisible challenge that we love to hate
We fought on the security frontline at Apple for about 10 years. Our mission was simple: to attack products using any means necessary and then work on the fixes with development teams when applicable. We discovered hundreds of vulnerabilities and often had to deal with the usual Developers Vs Security conflict.
The unfortunate reality with application security is that most vulnerabilities discovered cannot be fixed on time, and vulnerable code is often released before developers have a chance to fix it. Fair decision, but releasing vulnerable products is not something that you can feel comfortable about. These experiences highlight the current limitation of manual security assessments with continuous development.
We’ve often heard developers should write secure code. Security bugs are just a subset of common bugs, and we all agree that writing reliable code is always better than writing buggy code. Fair enough, but who writes code without any bug?
Security experts and developers have almost no intersection and often have misaligned priorities. The approach, the vision, and the respective skills rarely overlap. One of the most important thing to understand is: not all developers love software security. Just hang out in meetups and ask. This is quite an unfortunate statement for security addicts like us.
Everyone has good reasons to ignore application security [pick up yours]:
- “I am running out of time”
- “… And anyway, my app framework is secure enough”
- “… And what sort of attackers would target me btw?”
- “… Anyway, don’t worry, I run a security assessment every year!”
Exposure to attacks is generally related to the success of your company. Most people who experienced security issues have probably raised one or two of these objections in the past.
Developers embed various technologies into their applications to enhance reliability: performance monitoring, exceptions handling, logging facilities. What about security?
Why developers hate security
Developers are running out of time to build their own features and most of them just don’t consider spending hours on invisible things that won’t directly benefit to their customers. Writing reliable, maintainable, and fast code is already a challenge. Security is a pretty thankless task that is often left behind. Let’s check some of the symptoms:
- Security is not considered as a feature. It’s currently seen as an additional layer of complexity and colleagues don’t like merging such pull requests.
- Implementing custom protection is error prone, complex and time consuming.
- Code is moving fast. As mentioned above, manual assessments (i.e. penetration testing) and continuous development have a hard time living together.
- Apps intensively rely on external dependencies. Any flaw in one of these could put your entire app at risk.
Continuous development drastically changes the place of security within the development process.
Technology is complex. Products shouldn’t be
The race to build simple and robust security product
One of our strongest priorities at Sqreen from day 1 is to reduce friction to the minimum: onboarding, deployment, use, experience, integration. Our technology is complex, but our product is not.
Our mission is to build security products for all developers. Any developer, not just security experts. Exposing complexity is unacceptable, so we’re pushing back hard to make the most simple and powerful product.
Building products that can be used by everyone might sound obvious, but most security products today are way too complex for anyone who isn’t an expert in the field, and are often some of the most poorly understood pieces of software.
We faced three main challenges to shape the best experience:
- Deployment and configuration. We understand that developers don’t want to spend more than a few minutes installing a security product, and most likely wouldn’t want to have to modify their code for this purpose.
- User Experience. Security products usually require specific skills. Why a security product should be drastically different from other development tools?
- Community. Attackers are moving fast. Security events triggered in our community should be used to generate dynamic protection and benefit all of our customers.
Protecting web apps at the network level
The traditional way to protect web applications is to use Web Application Firewalls outside the apps. They basically redirect the traffic, inspect it, and filter out potentially harmful requests. They act as a fuse and stand at the perfect place to protect against denial of service attacks, however, when it comes to protecting against vulnerabilities, they face several limitations:
- End-to-end encryption is already a standard. Traffic inspection requires unencrypted data, exposing both customers and applications to wiretapping or tampering.
- Inspecting flat network information is error prone. Network based information only contains a limited amount of data, which lowers filtering reliability. Partial encryption or unsupported encoding will not prevent them from protecting the apps.
- Vulnerabilities and protection patterns must be symmetric. Technologies based on a list of patterns must be symmetric to threats. Each newly discovered vulnerability should be supported.
- High amount of maintenance.
Web app protection — building a developers platform
Sqreen is agent centric: each application is reinforced by a protection and monitoring routine, directly inside the app.
The Sqreen agent is installed inside the application as a component. Traffic is not redirected and the protection is handled directly in place in the application. Sqreen is quick to install and can provide instant visibility of security threats.
Sqreen provides protection against web vulnerabilities like SQL or command injections, cross-site scripting (XSS) and data exfiltration, in addition to protecting against specific attacks like ShellShock. Sqreen also monitors and protects against suspicious account activity: account hijacks or bruteforce, accounts created from flagged attackers, signins performed simultaneously from different locations (signing up from Brazil and Nigeria simultaneously for the first time can be suspicious!).
About 85% of our customers include vulnerable third-party dependencies in their production application. Sqreen’s protection logic is not just limited to our customers code base but will also cover all installed dependencies. Sqreen will even warn customers whenever new vulnerabilities are published.
The Sqreen agent retrieves updated detection and protection logic on a regular basis to keep apps protection up to date.
We aim to build our product transparently and will share info about our technology with the community in future blog posts.
Community is key: protect your peers
Security expertise is rare and often exclusive only to larger companies, while hackers move quickly and can stay one step ahead. Attacks contain valuable information that can be extrapolated in order to enhance the logic and better protect the entire community.
Sqreen leverages all the attacks to make a stronger protection and to adapt continuously to the real threats.
Let’s check two examples among the vast possibilities offered by the approach:
- An attacker flagged from previous attacks, who creates an account on our customers applications, will automatically trigger a suspicious activity notification
- A vulnerability triggered in a CMS for the first time (zero day attack) and detected inside the application, will be sent to Sqreen.
Analyzing the patterns (URL, or any user input involved in the attack) allows us to enhance the protection coverage, and also report this pattern to the community. Stay tuned on that part, we will soon provide more information.
Give us a shout if you want more details about Sqreen, and don’t forget to make your next coffee break productive ;-)
Did you enjoy this article? Help us spreading our vision and product recommending it below, or on Twitter. We are @SqreenIO.
