Everything you need to know about application security
Most product companies have displayed clear intent to get their security right as early as possible in the cycle. However, depending on whom they talk to, the perspectives on appsec can widely vary, which makes it rather challenging for the company. Hence, the ultimate question is "Do they know what application security encompasses to take the right steps?"
We, at CyberSafeHaven Consulting, have laid out a few pointers for companies to self-evaluate and determine how ready they are. The list has been compiled from our interactions with multiple companies. We have tried the present the pointers in a logical top-down approach.
STRIDE is by far the most popular threat modeling technique that will come to our mind. STRIDE was adopted by Microsoft in the late 90s and was not actively spoken about beyond mid-2000s. The last article you will find on their website about STRIDE (not related to Azure) would be sometime in 2007. More recently, threat modeling and STRIDE are being pursued in the context of Azure. The frameworks (STRIDE and others) have not been widely accepted or practiced, primarily due to they being too esoteric in nature. The developer/architect combo had to decide the nature of risk and extent of exposure, which was not in the realm of their expertise.
We believe its time for a simpler threat modeling framework which does similar things as STRIDE but does not leave the world open but provides specific inputs to the people developing the product on security aspects. When the inputs are more specific and the dimensions to look at are more closer to the product features, they automatically translate into better security. For example, when STRIDE talks about "denial of service", is it about the web server, is it about the backend services or the DB, most likely all of them. The framework intentionally talks a higher plane but leaves a substantial amount of details to the imagination
Secure Architecture & Design
While scalability and performance are looked with microscopic details while building products, security is typically ignored, at least not given the level of required attention. The most defining aspect of security in the architectural review of software products is looking at the major components, how they interact with each other and with the outside world. The interfaces, data in motion and data at rest in each of these components need to be reviewed to determine if sufficient protection mechanisms exist. When the product keeps adding more features, or if a component is dropped or added, the security is intact, if done right.
At the design level, you look at more specific items like how the keys/secrets are being managed, are there compromises for performance enhancement? Another example could be around the choice of third party libraries, the extent of security vulnerabilities introduced by them and how can they be mitigated. A final example could be where, let us say, you want to secure a common confidential data or resource by encrypting it (but use a single private key), that can be accessed by several customers. Customers only need to authenticate themselves and then they have access to decrypted data, not the key itself. However, this is not very secure for most cases and hence at least adding a salt to each customer before encryption\decryption process, hence the key+salt combination makes it a bit more robust.
While the good part about API security is that it is on most companies' radar, the unknown part is if it covers all dimensions of API security. The appropriate choice of authentication mechanism (irrespective of direct authentication like APIkey or bearer token or you use an underlying framework like openID connect), the approach of a fine-grained authorization of resource, cataloging the APIs as public/internal APIs thus creating an inventory of APIs are some of the steps not necessarily given sufficient attention. For example, when an API for extracting history for a particular customer is being built based on customerID, the name, email/phone and other personal details are irrelevant. They should not be returned by that API and should strictly return only the history details. This way, integrating with 3rd party, if and when required, can come with very less security ramifications.
This is a very frequent and rather costly mistake that most companies overlook. How the private keys, secrets in code and access credentials are managed is very critical and needs close attention. Embedding credentials for DEV environment but using Vault for production but retaining the same credentials is equally costly. Hence, maintaining a uniform process is always recommended.
Business logic flaws
This is the hardest for tools and external applications to catch but can break a product completely. A music streaming company allows legitimate subscribers to access songs after authentication. However, even on unsuccessful authentication, users can view the path to the final resource although they might not have access to it but is deemed highly risky. Such business flaws can easily cut across design, product implementation and cloud security.
Fortunately, OWASP Top 10 has renamed "insufficient logging and monitoring" to "Security Logging and Monitoring failure" as a security risk. We state this because many times, product logs contain more than required information becoming a major source of reverse engineering the location of the database, port making it rather easy to breach. Given that there are stricter regulations happening across the globe, it is highly pertinent to have a logging strategy. A good logging strategy should contain the following: a) what information to collect, b) where it will be stored, c) who can retrieve what portions of it and d) how long that will be stored before moving to a secure archive. What if sales for my product has suddenly skyrocketed and I need to seek help from external organizations to support customer requests, will and can I suddenly change my logs on-demand or should be well planned?
Often DevOps engineers tend to believe that a VPC is the solution to entire cloud security. All front-end, back-end nodes and databases are all within the same VPC behind a CloudFront/CDN, giving a false sense of security. Appropriate segregation of the web servers, front-end nodes, back-end nodes and accessibility from each segment to others are usually neglected. OSINT, nowadays, can reveal all kinds of expensive misconfigurations within minutes, if not in seconds. DevSecOps needs to be very comprehensive and all the way. Software composition analysis (SCA), static code analysis (SAST), dynamic analysis of applications (DAST), scanning of virtual machines or containers, as the case maybe, for identity and vulnerabilities even if from private registries are some of the important steps involved. Last but not the least, a complete cloud security audit would be highly recommended.
In summary, application security is not just VAPT or merely shifting-left (DevSecOps) or cloud security or any subset combination. It would be reduced to a piece-meal approach. As seen above, there are more dimensions to the application or product security. The sooner we acknowledge the same, we can build more secure product together. All of this can be overwhelming to some organizations. They can be easily torn apart from choosing between having an "in-house" security expert versus installing a plethora of security tools.