Application Security Or Network Security, Do I Need Both?
The short answer – YES.
Take a moment to think about the last ten years in the software and technology industry. I bet most of us could come up with more than a few instances where data was stolen, sold to the black market or just had your email account hacked into. So what do we do about it?
When most people talk about security in the technology space, they start talking about IP address restrictions or firewalls, threat monitoring for DDoS attacks, load balancing for traffic spikes, etc. These are great network related security and reliability discussions, but they don’t get at the heart of some of the breaches organizations have had in recent years.
There is a nonprofit called OWASP (Open Web Application Security Project) which was founded to improve the security of software. They published a list of top ten security related issues that create attack vectors for hackers to compromise your software. Spoiler, OWASP has been around for almost TWENTY YEARS and some of these items are still on the original list. DevRite takes application security seriously. Every application we build, each and every one of these items below are taken into account. We have invested thousands of hours into our base toolset we deliver to each and every client. Lets talk about the top ten list and what DevRite does to keep your data yours.
This spec talks about injection attacks, essentially this happens when you take a field on a page from a user such as an email address and directly use that input (without sanitization or validation) and execute it to a database. This problem is particularly simple to solve. 1) Use parameterized database statements or 2) Use an ORM (Object-Relational Mapping) for database access. DevRite uses Entity Framework, a Microsoft recommended ORM for SQL Server.
This spec is related to session management, and browser cookie or token safety. An attacker attempting to utilize this flaw would try to steal your session and pretend they are you and thus maintain their anonymity and assume your access level. (Yikes if you’re an Admin!).
A3:2017-Sensative Data Exposure
This attack is related to getting access to data you shouldn’t be able to get to. Either via direct data access because of encryption or physical access to the data itself. DevRite stores all information in secure cloud facilities and ALL data is encrypted both in transit (over the wire) and at rest (when the database is not in use).
A4:2017-XML External Entities
XML is an older technology, but basically this is referring to an attacker that can request a file they shouldn’t have by manipulating request objects that are intended to return files – they just ask for one they shouldn’t have. DevRite doesn’t use XML based requests unless a third-party tool we are integrating with requires it. This attack doesn't affect your application directly because we don't build the apps using XML based APIs. Most of the security concerns here are with SAML based SSO, or SOAP API's. DevRite uses OpenId Connect & OAuth 2.0 to facilitate SSO and our API's are not SOAP based. If we must integrate with a SAML client to facilitate SSO - we will ensure that the XML parsing library they are using is patched to prevent this attack from taking place.
A4:2017-Broken Access Control
This one is similar to broken authentication, with a key difference - manipulation of URL's or HTTP types (get, put, post, delete). Lets assume you have a site that loads company information at https://thebestwebsite.com/company/345, notice the 345. Imagine this was behind a login and you had to authenticate yourself to see this URL. If I put 346 at the end of the URL (which is likely a totally different company) and it loads the data - Bingo. You have now just allowed someone to view someone else’s company information without authorization. DevRite has developed a toolkit that we integrate into every application at the database layer. We validate and check to make sure that the person who is requesting it can access it, and should access it before it ever leaves the database. That means we ensure that if they aren't supposed to even see it, it never goes over the wire either.
This one is tough and always prone to error since humans are configuration systems. This spec is here to highlight the importance of updating third party software such as windows or SQL server, because as your providers find bugs, you want to make sure your application gets those latest security patches. DevRite maintains these for you if you are on our maintenance plan. If not, we recommend keeping tabs on releases of the tools that are being used in the project. We provide a comprehensive list upon request for each tool and its version number at the time of delivery should you choose not to have us take care of hosting and maintenance for you.
A6:2017-Cross-site scripting XSS
We also make sure that a Content Security Policy (CSP) is used for every web application we make.
This is related to web requests when the server attempts to change things into something it can understand, when doing so, malicious code could be executed during this stage. The best way to handle this is to never use generic types. Log every failed deserialization request. Sanitize and validate the data. Seeing a pattern here? When we create your custom applications, usually the API's are secured in such a way that we trust the source of the incoming data. However, this isn't always the case and since there are always exceptions we make sure that the API's we build handle the lowest common identified issue. Since some API's are public (such as APIs you want to expose to sell as a product), we make sure that we never use generic types for deserialization. This virtually eliminates this spec and ever other request failure is logged.
A8:2017-Using components with known vulnerabilities
A9:2017-Insufficient Logging & Monitoring
This one is related to auditing and threat detection. When something does happen, most applications don’t have enough monitoring or logging to figure out the attack vector to find out more information and even to identify the attacker themselves. Worse yet, they don't have any tools to alert them the problem is happening. DevRite understand the importance of monitoring and logging, and as part of our hosting features we incorporate a baseline application monitoring as part of our default benefit.
Wrap it up
Lets summarize - what is important here is that DevRite has you protected for all of the top 10 items on the list for application security. The reality is attacks can and do happen. Our job is to make sure we build something for you that has Defense in Depth, so if one of these techniques happens to fail, there are other safeguards in place to make sure that data isn't leaked. Example, if an attacker does happen to gain access because of a newly discovered vulnerability, even if they call an API with improper URL (because they're guessing to get more data) they can't get it, because they still only have access to what the original user has access to. The only risk is the risk already taken by your organization to allow that particular user access to the data they already own.
Ready to get started on your next big idea? Let us work with you on how to get your idea off the ground with the best support, security and tools the industry has to offer.