Retrospective: NASSCOM Cognitive Security Meet – 2017

With a rapidly evolving technology innovation landscape, a paradigm shift in our approach towards security is necessary. The transition of the outlook towards cyber security in India is changing from reactive risk mitigation approach to a more holistic readiness to protect against the escalating cyber threat landscape. Management attention of various organizations to Cyber security at the Board level in the Enterprise and PMO in Government has increased. The Best Practices Meet threw light on use cases and aspects of cognitive computing that are shaping the security technology market. The two – day meet touched upon topics like DevSecOps, GDPR implementation, cyber defense centers, AI, machine learning and the likes.

Mayank Lau and Shomiron Das Gupta of Data Security Council of India (DSCI) opened the first day with a  Cognitive security workshop. The workshop focused on bringing about the differences between using Machine Intelligence and Business Intelligence, finding patterns/insights in the data. It further emphasized on creating an ecosystem where capabilities of cognition could be used to deliver intelligent, lightweight products of minimal complexity.

DevSecOps, a practice that has been pegged as the antidote for security pain points in product development was deliberated upon in two panel discussions.  Echoing the very essence of DevSecOps that we45 has been practicing, it emphasized the role of DevSecOps in helping organizations develop quality and secure products by implementing security in the overall development process. It underscored the importance of setting up a common ecosystem for an organization’s activities which ease out security checks, patch management for security and the likes.

Security by design, a lean concept, was further explored by inquiring into methods like least privilege access, defense in depth, minimising attack surface, providing and maintaining traceability to requirements, threat modeling, usage of least vulnerable third party OSS components, usage of SAST and DAST tools, performing third party OSS vulnerability checks and so on. In addition to the principles of secure design, importance of security patch release management, patch management for AI modules, discovering unknown vulnerabilities , usage of Machine Learning to detect changes in the code for breach management were also discussed.

Amita from we45 in discussion with the panel

The second day opened with panel discussions on Cognitive security and self-learning systems.With the help of use cases, the discussion tried to identify the underlying capabilities and possibilities cognitive computing brings, the impact of cognitive computing in different domains and ways in which cognitive computing helps to tackle security problems.

Adding a layer of AI to Threat Intelligence and hunting operations was something that caught my fancy. The insufficiency of traditional signature based methods for attack detection, security solution evolving from being threat based to unified solutions, emphasis on technologies like AI, Machine Learning giving a significant boost to an organization’s security operations and threat intelligence centers and future of AI based cyber security were discussed.

A short, yet interesting session deliberated about “Reposing trust in the citizen identity system” – the session emphasized the importance of having a unique identification number, the security issue it poses. A  panel discussion between the security heads and lawyers saw many important questions being answered.

An interesting talk by Sahir Hidayatullah, CEO, Smokescreen, covered topics like adversarial machine learning, finding patterns and scaling, network isolation and cryptography, mirage maker, attacks against the ML algorithms, applying traditional military history methods to cyber security, threat hunting, reconnaissance, intersection of methods of defence and attack, Honeypots / deceiving the attacker, modelling based on the thought processes and actions of the hacker, early threat detection, freezing/isolating compromised parts of the system etc.

The event ended with a plenary session on the Ramification of AI, IoT, Industries 4.0, Blockchain and Encryption dominated world on life, society and economies and the need for decisive policy intervention.  They enquired into the need for India to bring these areas on its policy agenda and all the related issues to be addressed, the ongoing policy initiatives related to AI IoT Blockchain Encryption and Industries 4.0, the role of policy intervention to boost the development and adoption of these technologies.

The conference tapped into interesting areas of the ML ecosystem. As interesting as the test cases were, the translation of theory into implementable ideas was missing from the deliberations. It’s commonplace for practitioners to wrap cyber security and AppSec into the same fold but, addressing the diversity in applying AI to both these domains is the need of the hour.


WannaCry in the AppSec World

There is literally no way anyone could have avoided hearing about “that ransomware attack” which crippled millions of computers all over the world. The WannaCry Attack has made waves across technologists and non-tech folks alike, and has made several folks definitely wanna cry, as they see their critical data encrypted and completely unavailable.
As a quick refresher, the WannaCry ransomware attack has emerged from the aftermath of the infamous Windows vulnerability MS17-010. An Attacker can send specially crafted messages using SMBv1 (Server Message Block), execute code on the remote server and gain access to the server as a privileged user of the computer. This affects multiple categories of windows products, including Windows Server 2008, 2003, 2012, XP, Vista, 10 and other windows OS products. The patch for this flaw was released by Microsoft in March 2017. However, it was only a patch for currently supported products and not older products like Windows XP, Server 2003 and so on, which still has a massive user base. The code from WannaCry is said to have emerged from the exploits stolen by a group known as the Shadow Brokers from the Equation Group (a cyber threat actor that is supposedly linked to the USA’s National Security Agency (NSA)). The malware, known as WannaCrypt0r has been used to perform the WannaCry attack.
The worm is extremely effective against unmatched Windows hosts, where it loops through the RDP sessions on the system, attempts to identify hosts on the network, loads the payload on the remote computer and scans the network for additional hosts to infect on port 445.
A detailed technical description of how wannaCrypt0r works is available here for those interested to read
Adrien Guinet, a security researcher has released a decryption tool on May 18 that will be able to decrypt the ransomware without the users having the pay the $300 ransom. This works on several OS variants, but not all affected variants:
wannaCry is a wake up call for the industry and holds scary prospects for the application security world as well. With Applications, we use several third party libraries, frameworks and open source code that is often vulnerable to several security issues. In addition, vulnerabilities against these popular frameworks can easily be weaponized and used to decrypt sensitive/mission critical datasets for organizations. These can be fatal to organizations relying on these apps for their day-to-day operations. In fact, we saw a glimpse of this possibility when the Apache Struts2 Remote Code Execution flaw was identified, and everyone who got hold of the exploit used it to perform “tests” against any application out on the open internet.
I feel that its only a matter of time before ransomware payloads start making their way into Web Apps.

OWASP Top 10 2017 and the new age of Application Security

We, in the security industry love the OWASP Top 10. For one, it has a catchy name. But more than that, it has a simple way of grabbing people’s attention and focusing them towards application security using the concept of a simplistic list. The OWASP Top 10, released by the Open Web Application Security Project every four years, has become a benchmark that the entire industry rallies around, for application security. So much so, that the OWASP also has similar lists for Mobile Application Security and IoT Security.
OWASP has created its first Release Candidate (RC-1) for the year 2017. While this document is still under review and is open for comments from the community, it is a complete document that will probably have minimal changes, if any before it is released to the world.
What’s the OWASP Top 10?
For those who are not aware of the OWASP Top 10; The Open Web Application Security Project (OWASP), was founded in 2001 as a not-for-profit organization. OWASP is an independent body of industry professionals and application security leaders who come together and contribute to a single cause. Making applications more secure. OWASP and its community has a prolific output of application security artifacts in the form of articles, books, tools and so on. They have conferences across the globe where leading minds in application security discuss the latest and greatest techniques and practices in making and breaking secure apps.
One of OWASP’s most enduring documents is the the OWASP Top 10. The OWASP Top 10 is a document that captures the key risks and weaknesses that are facing apps all over the world at a given point in time and capturing the Top 10 categories of application security risks. This document is used extensively by organizations and security practitioners all over the world. Not only does it provide a detailed analysis of security risks to applications, at a given point in time, but it also provides specific details capturing the nature of the risks, including Exploitability, Prevalence, Detection, etc. thereby creating a more holistic view of security risks, rather than focusing only on the “weakness” per sé.
What’s new in the OWASP Top 10 2017?
The OWASP Top 10 2017 is important for many reasons. In my opinion it has highlighted and captured several key elements of information security that are relevant for today’s apps. Let’s take a look at some key changes in OWASP Top 2017 vs OWASP Top 10 2013.
Merging of Access Control Based Vulnerabilities
Attacks against access control are one of the key ways in which hackers look to compromise applications and gain access to sensitive information. Since 2015, we at we45 have seen a dramatic increase in Access Control attacks as compared to most other classes of attacks, including Cross Site Scripting and SQL Injection, with the latter becoming rarer and rarer, simply because modern application frameworks automatically perform encoding and parameterized SQL queries using ORMs (Object-Relational Mapping). Attacks against Authorization, like Insecure Direct Object reference attacks and Authentication Attacks, against sessions or tokens is a more pernicious set of attack vectors, especially with Single Page Applications and API-style applications becoming the norm. Access Control hasn’t been made into a highly generic style of security protection, as developers implement their own access control routines. The OWASP Top 10 rightly classifies all access control attacks including authorization flaws under a single category called “Broken Access Control”.
Under-protected APIs
With the rise in client platforms and distributed computing, the world is clearly moving towards creating APIs as opposed to typical browser-focused web applications. APIs are the invisible glue that bind multi-platform/client applications to a particular set of web services, be it mobile apps, Smart TVs or other applications. While APIs might be web applications, securing APIs is a little different from securing typical web applications. There could be a bevy of attack possibilities for APIs ranging from the standard injection attacks to more complex authentication bypass flaws, token based information disclosure flaws and access control flaws. Flaws like XML External Entity Injection, where a vulnerable or poorly configured XML parser can be leveraged to perform devastating attacks against the application can be leveraged against Web Services or API-style applications.
Insufficient Attack Protection
This is a departure for the OWASP Top 10. While the OWASP Top 10 typically focused on Application focused risks, this OWASP category is typically “outside the application”. This category focuses on “detecting, responding to, and blocking attacks makes applications dramatically harder to exploit”. I for one welcome this, because there are fundamental flaws in Application Security programs used by organizations, where there is too much focus given on preventive security measures, and hardly any time and effort put in to detective and corrective security measures. Detection includes techniques like Vulnerability Assessment, Penetration Testing, Deploying WAFs or RASPs and corrective refers to releasing virtual or real patches for the flaws to protect against attacks.
One of the other challenges with today’s distributed apps, is the challenge of monitoring. Monitoring complex, distributed apps is an art that most companies don’t get right. However, with ready tech available in the form of the ELK stack (Elasticsearch Logstash and Kibana) or Splunk, etc, this has become much easier to do today, than ever before.
Continuous Application Security Testing 
At we45, we couldn’t be happier at this year’s OWASP Top 10. It has reinforced an age-old tenet that we have been advocating to the community at large. Today’s apps are usually in rapid-release, agile environments where apps undergo constant changes in the form of new features, UI and so on. There is a need to ensure that apps are continuously tested for security vulnerabilities. This can be in the form of leveraging automation for SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) and creating automation for manually identified exploits as well. This is the essence of Security in DevOps, which promulgates that application security vulnerabilities should be discovered earlier in the lifecycle, rather than later, where the security flaw might make its way into production, causing a great deal of disruption.

The Most Secure Application Development Language

One question that several people have asked me over the years is this “Which is the most secure development platform/programming language in the world?” It is an honest question. It is quite pertinent, given the state of application security across the globe. However, it is akin to asking the question “Which language allows me to speak the best?” The answer to that question is “all of them” or “none of them”. Today, on the web, we have several languages/platforms/frameworks vying for attention. All of these languages have their disciples and zealots. Yes, you even find them for languages like Perl (to be taken in the right spirit). Nevertheless, I would like to provide a glimpse into the current state of security of these programming languages and platforms, to give the most suitable response that I can provide for the question that most people ask me.
Firstly, let me start off by saying this. In my opinion, programming languages and platforms are like tools. A skilled and security-conscious developer can do amazing things with these languages and platforms. I can safely say that a developer who is aware of security requirements and their impact on an application, is truly the best defense against attacks. However, that is not the purpose of this article. For this article, I will divide my analysis into two segments, they are:

  • The Established Order
  • The New(er) Kids on the Block

The Established Order

The Established Order consists of languages and frameworks that have been used since the inception of web platforms. I am principally referring to Java, ASP.NET and PHP. I am going to ignore CGI and Perl simply because, I believe that most modern development across companies that I encounter do not depend on.

Lets start with PHP. PHP is a security tester’s dream. I have seldom found a secure PHP application that I have truly respected for its security implementation, which is scary because PHP is an extremely prevalent programming language on the interwebs. In addition, the simplicity of the language and the sheer number of PHP products (WordPress, etc) dominate the world of the web. An established PHP developer told me that the reason that PHP is so widely maligned from a security standpoint is that the language is splintered and distributed (a claim that I am not entirely sure of). Nevertheless, I find a rash of vulnerabilities with PHP applications and I can safely generalize that I find most of the highly vulnerable applications developed on PHP. Having said that, newer implementations of PHP that use frameworks like Zend and CakePHP seem to have handled several issues that we used to encounter on a routine basis.

Java has gotten a status of being an “enterprise platform/language”. I have seen Java either being used by Banks and Financial Institutions or established internet companies like Amazon and Google. I have observed that while Java devs seem to have handled Authentication issues, session management implementations with great comfort, I have seen several failings in Direct Object Reference attacks and Cross Site Scripting. The good thing with Java is that you have a great deal of code examples, lessons and tutorials on securing Java Apps, however, I still find that XSS and Direct Object Referencing issues are pervasive across most Java Apps that we test at we45. Java provides great strength with reference to Crypto and I find that log4j single-handedly simplifies Logging and Log Management for Java. However, more programmatic security issues still persist with older Java web apps. Today, we have some great Java web frameworks like Spring, Play and Vaadin that handle several security issues right out of the box.

ASP.NET is a surprise on the web platform front. It is also an extremely popular and powerful platform that has been used extensively in several applications that I run into. Although one might scoff at Microsoft for its security flaws (in the OS), they have done great work with promoting and promulgating security features into the platform. I see very few issues with XSS, SQL Injection, Session Management, etc with DotNET, However, I still see Business Logic, Direct Object Reference and Authorization Flaws with the platform. I also find that DotNET Developers are more aware of security issues and impact as they seem to have several security references in their reference materials and API Documentation.

The New(er) kids on the Block

In this section, I focus on languages/platforms like Python (Django), Ruby on Rails, Angular, Node and so on. While some of these languages are not exactly “old”, I have seen some modern applications and new-age product companies use these platforms and frameworks in their products.

Let’s start with my personal favourite, Django (Python). I love Django. It is extremely simple and abstracts away all of the niggling security-related issues that you see requiring explicit attention with other platforms. Django pretty much solves XSS, Password Encryption, SQLinjection, Session flaws, Auth flaws, XSRF and Host Header Injection right out of the box. Its less verbose and highly effective to be used even for apps with massive scale (we45 ’s own apps VMA and SecuritySlate are 100% Django and scale like nobody’s business). However, all this security sometimes dulls developers into thinking that they are invulnerable and they make serious errors in Business Logic Flaws, Direct Object Reference and other flaws. In addition, Django does not directly allow the use of Indirect Object maps, which makes fixing Direct Object reference flaws, a little cumbersome to say the least.

Ruby on Rails has made some impressive strides in security. However, some of you might remember that Github had massive security failures due to some insecure implementations of ActiveRecord and Mass Assignment in Ruby on Rails. Ruby on Rails devs also had some security nightmares in 2013 (read CVE-2013-0156). However, in my opinion things have been rather quiet on the Ruby security front since then. Ruby also enjoys some great APIs and apps that really make a developer’s life easy when implementing security. Apps like Brakeman and Codesake are highly used and appreciated by the Ruby Dev community. Rack is a middleware component that enjoys massive usage for its inbuilt security protections.

Angular JS and Node JS are defiinitely new kids on the block as they are used by the latest apps. They are usually used in conjunction with NoSQL Databases. I find that NoSQL databases are implemented in a very in-secure manner and thus we (at we45) find issues with these applications. We also see CSRF Issues and Web Services Auth Bypass issues with these apps. We also see HTTP Parameter Pollution with AngularJS Apps implemented with NoSQL quite often. Of course, we see some XSS attacks as well.

I think by now you would have understood that languages/platforms and their frameworks can facilitate security and its implementation. As I mentioned earlier, the most important defence against an application’s attacker is a skilled and security-conscious developer and an organization that has planned, implemented and tested security extensively across the lifecycle. No language/platform or framework can serve as a defence against negligence and lack of awareness.

The 3 Most “Resistant & Persistent” Application Security Vulnerabilities

My team tests at least 5 applications a week on average. We constantly work with Web Apps, Web Services, Mobile Apps and now, IoT driven applications, which have a pretty large web services layer supporting it. We work with multiple product engineering teams, especially developers, to help them fix those niggling security problems. Recently, I had a question that I wanted answered in substantive terms. “Which vulnerabilities are most resistant and persistent across all the apps that we test?” This is a pretty expansive question. We test scores of apps, that have a larger set of vulnerabilities. I was looking for application vulnerabilities that either haven’t been fixed over time or have been fixed at a given time, but have resurfaced elsewhere. These vulnerabilities, I would put into the “Resistant, Persistent” category. I loaded our sanitized vulnerability metadata onto an ElasticSearch Server. And armed with my python scripts for analytics and aggregation, I crunched some numbers and I have tried to drill down to the 3 Most Resistant Application Security Vulnerabilities, from January of 2015 to the present day.

Cross Site Scripting (XSS)

There’s nothing new about Cross Site Scripting. Its been a permanent fixture on the OWASP Top 10 as far back as I can remember. One would think that Cross Site Scripting (XSS) would have been fixed or at least marginalized by this point. However, unlike SQL Injection, Cross Site Scripting has continued to enjoy relevance and multiple leases of life. This is simply owing to the fact that the application attack surface has increased significantly with tons of third party Front-End JavaScript libraries, inconsistent output encoding, dependencies on CDNs, etc. Cross Site Scripting has proven to be a formidable vulnerability to fix. Nearly everly client we test seems to have atleast one or more significant Cross Site Scripting flaw. This, despite the fact that modern web frameworks come with “batteries-included” approaches to validation and output encoding. So, if you’re app is using any of the above elements that I just mentioned. You need to probably look for this highly resistant and persistent security flaw.

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference really are Authorization Flaws. Using these flaws, an attacker can bypass permissions management controls and gain unauthorized access to sensitive information from other user accounts or other data  sets. The major manifestations of IDORs happen in two ways. One, (more uncommon) where the attacker is able to manipulate model data and gain access to privileged functionality . The other manifestation (more common) is one where attackers can identify primary key/identifier values and attempt to gain access to other user accounts or elevate privileges. The reasons for this vulnerability being “resistant and persistent” is due to the following factors:

  1. There’s a lot more impetus given to authentication than authorization in the design/architecture of an application. What’s worse is that authorization is a highly design centric activity that is usually done poorly. Its not granular enough, its not comprehensive enough and its coverage is inadequate. So, its doomed to fail.
  2. With Web Services (where’s there’s no UI Control) this is rampant because developers just don’t expect/realize that there are these bugs in the system.
  3. These vulnerabilities cannot be tested directly with Automated Vulnerability Scanning tools like AppScan, Burp, etc. They have to subjected to manual/scripted security testing with special impetus on authorization testing.
  4. The other (probably smaller) reason is that developers don’t design primary keys to be truly random. Some of them are basic incremental integers(1,2,3) or what they think is random(20160327001), which I am sure by now, you realize is anything but.

Direct Object Reference flaws can be deadly. They need to be understood and addressed the right way.

Cross Site Request Forgery (CSRF/XSRF)

Cross Site Request Forgery is really an attack against Authentication. In short, an attacker is making the user do things the user never intended to do on your application. This could be anything from forcibly changing the user’s password to adding an unauthorized rule on a firewall web console. Most of the web apps we test, CSRF is a common finding. The effects of a CSRF are only aggravated with XSS on the same application. To developers who think that CSRF only works on browser based web apps, think again. Web Services can equally be affected by CSRF Attacks.

Disclaimer: What I have written above, is in no way a comprehensive list of application vulnerabilities. These are just the 3 applications that my team and I are seeing more frequently than others in modern applications. These vulnerabilities happen to be both resistant and persistent because they seem to either stay unmitigated (for long periods of time)

This article was originally published on Abhay Bhargav’s LinkedIn page

3 Things to Make Your Application Security Suck Less!

All of us have problems. Some of them big and some small. Then there’s Application Security. In my discussions with technology heads of high-velocity application companies, they come up with a single problem. Application Security. “We can never seem to get ahead of the problem”, they say, wearily as they try to remediate findings from their latest penetration testing or vulnerability assessment report. Release cycles are delayed or heavily compromised, customers are unhappy over security flaws or you are constantly on edge about some hacker (or script kiddie) completely owning your application and putting your company on the headlines of the front page of next day’s news, and subsequently have “expert bloggers” like me writing articles like “5 Things you can learn from So and So breach” Let’s face it, your application security sucks! But don’t fret, there’s hope yet. In my opinion, there are 3 very critical things that organizations miss out on when trying to fix application security. This is not typically testing or secure coding or any other typical solutions that you would have come across. I am going to use stories to make my points. Here goes…

The $1 Hotel Room

We were recently testing a large and significant SaaS Solution that integrates with some of the biggest hotels and hotel chains in the world to give them easy online booking and customer relationship management solutions. They are a highly competent and technical team that has a good understanding of security. They were confident of their ability to have thwarted the OWASP Top 10 categories of flaws and were handing over their app to us for a penetration test. During the pentest we found that their web service was vulnerable to a integrity flaw, where we were able to bypass their checksum controls and manipulate booking amounts for hotel rooms. We were able to book a hotel room that was worth $650 for $1. Needless to say, they were shocked and admitted that they needed some time to fix this flaw. During my discussions with their VP of Engineering, I asked him why they had missed an obvious flaw like that. He said that they had looked at flaws like SQL Injection, Cross Site Scripting and what was considered “typical OWASP Top 10” flaws and had focused on the controls and counter-measures to address that.

This “Control-driven” Application Security culture is quite rampant. Companies use “lists” like the OWASP Top 10 and SANS Top 25 to dilute and create a bunch of security countermeasures that would address the vulnerabilities expounded in these lists. They completely miss out on business logic flaws and business-focused flaws because they don’t think “Threat First”. I have personally seen and implemented Threat Modeling Frameworks for organizations that has delivered amazing results as these companies were forced to think “Threat First”. This form of thinking gets you to analyze and detail some of your most critical threats in both business and technology terms and come up with high quality counter measures. In addition, these can be used as “security test cases” to perform detailed security testing for these Threat Models.

There are many ways to model and inculcate a “Threat First” thinking, including Threat Modeling, Table Top Simulations, etc.

Me and my Dependents

During a pentest for a major cloud application company recently, we identified a pretty serious authentication and session management flaw. For some reason they were failing to invalidate their Auth Token and their web service could be spoofed quite easily, if an attacker figured out the steps to do so. Turns out that the PaaS platform that they were using had a flawed token expiration call that didn’t really invalidated the Auth Token, rendering the application vulnerable to spoofing and similar attacks. Then, in the same pentest, we found a serious flaw in their Crypto library as well. In an age of modular applications rife with large number of dependencies with their own set of dependencies, this is becoming the biggest problem that tech teams have to deal with. Security flaws in underlying libraries, server components (in an ever increasing stack) and other executables are causing much pain to technology teams.

Unfortunately, there aren’t many great ways of addressing this other than certain customized solutions. We were shocked when we found that vulnerabilities in one client environment were cut by 65% when we implemented a security dependency management solution that we had developed for them. It became an integral part of their CI/CD process. Either way, the first way to tame the problem is to make an inventory and constantly update the inventory based on changes to the application. Luckily package managers and build tools provide functionality to extract and store this information for use. Once this is done, manual or automated investigative techniques must be used to identify and actively remediate security threats from dependencies.

“We have a tool”

I am in awe of marketing departments at some of these security companies. They make it sound like their product can find anything from SQL Injections to a needle in a 1 ton haystack. Their products are sold as a panacea to InfoSec and AppSec teams that are looking to solve their security problems with one or more of these tools. Unfortunately, these tools can’t find crypto bugs, business logic bugs, authorization bugs, authentication bugs, advanced SQLi bugs, Advanced XSS bugs, and mostly bugs with web services or slightly complex RIA frameworks. See where I am going with this? Tools are great, we all use them. I use them a lot, but I also understand that each app is different and tools can only help you with low-lying security flaws and point you in the right direction. Missing out on Manual testing or scripted manual testing is like missing out on the main course at the buffet. You’re going to remain hungry while someone else has your food. A very revealing statistic was when we integrated manual security testing into the CI/CD pipeline of one of our largest clients and they were able to identify and eliminate 100% of their critical and high vulnerabilities even before it went to Staging. Believe me when I say that there’s no better way to test an app as with a combination of manual and automated, that a purely automated tool can’t even come close to uncovering.


This article was originally published on the author’s LinkedIn page.

Sustainable Enterprise Security

Over the years with information security, I have come across a lot of challenging situations from negotiating a security fix with a team or bringing about process changes or change in the way security is perceived altogether. Given the sheer size of the security landscape, there are many security alert ingress points that need to be looked at on a day-in & day-out basis to ensure security of your enterprise.

Security artifacts from Threat Modeling, Architecture/Design Reviews, Code Reviews, Vulnerabilities in consumed 3rd party libraries, In-House and 3rd party VAPT, Customer Security Concerns, Changing Threat Landscape, APT, Alerts from SIEM etc. could prove to be overwhelming and a security personnel can easily get lost in this huge set of information unless there is a clear prioritization matrix and a lot of automation to help filter false positives and arrive at actionable insights.


In retrospection you may discover that we need to invest a lot of time in filtering out false positive and do context switching to cover various ingress points. In the current threat landscape we cannot afford to miss any security vulnerability citing the scalability problem of the security team.

What we need is automation of most of these repeated activities, build a correlation to learn, understand and dwarf attack vectors, share information among the security community to help other enterprises as well.

The challenge that security community faces is also of scalability. I have seen wonderful results in terms of securing the products by empowering the engineering community with security mindset and formulate a rewarding ‘Security Champion’ program within organization. The champions acts as extended team and understand the dynamism of the product better than any interacting security team would ever be able to achieve. Security is also about communication, relation, trust, common sense and commitment. I mean ‘Do not try to solve everything with technology’; sometimes there are simpler & innovative ways to address a security threat.

Another challenge in the security is the neglected behavior towards security issues over other functional requirements. Mostly every organization has a ‘risk acceptance’ process that business can use to defer a security issue for a future release. How do you overcome such a situation? This is where communication & trust play an important role, you got to establish the credibility with the team to influence the fix sooner than later. On certain occasions it is feasible to create a PoC to demonstrate the vulnerability but how about most of the cases wherein a full exploit will eat away your time and will impact other deliverables? Trust play’s an important role here that you developed by establishing credibility.

Often, the low severity security items are ignored or takes a lot of release cycles to fix. Everyone understands the ‘Power of compounding’, how about we apply the same to ‘power of chaining’ security issues and then analyzes the severity of it? The common vulnerabilities on a site that you would come across will revolve around ‘Mixed content’, ‘XSS’, ‘URL Redirection’, ‘Directory traversal’, ‘Banner Grabbing’, ‘Insecure Cookies’ etcbut when it is chained together it could result in a critical security flaw. The authorization bypass vulnerability by fuzzing mutable parameters in an API has been predominant and results in a devastating security flaw. It is basically connecting dots and architecting a complete exploit story. With rich functionality set of HTML5, deviations from RFC’s among different vendors, abundance of free app’s bundling vulnerable osstp and thanks to path management cycle, the attackers have all the time in the world to exploit the vulnerabilities before it could be officially patched.

So how do we ensure product security?

  • First understand the real threats to your product and then devise strategy to address it.
  • Prepare for the inevitable.
  • There is no alternative to penetration testing, implement continuous security testing approach that leverages standard & tailored security test cases to uncover any potential vulnerability.
  • Different vendors in this space are trying to prove their dominance, don’t get too excited about investing in off-the-shelf solution that may not be a right fit. Every enterprise has their unique security challenge. Look out for vendors that partner with your engineering team instead of just selling you a scanning tool.

3 Ways to WIN with API Security Testing

A very common impression I get from some folks in the industry is that security testing API is nearly the same as testing a traditional “browser-driven” web app. Well, That’s not nearly that simple.

Till recently, traditional (browser-driven) apps have been the norm. Many of them are relatively simple stacks that “scale-out”. They usually consist of a presentation layer, a business logic/app layer, some middleware and a data source(s). These apps were built with the browser as a client in mind. However, over the last few years, Web Services has become the norm, where the application is a set of services (more popularly, RESTful Web Services) that talks to multiple front-ends, including a browser front-end, mobile apps, other apps, etc. This concept has been further streamlined to micro services and server-less architecture that are all the rage today.

A lot of the web application security practices, especially around testing, typically revolve around the older-school of applications. Attacks like Cross Site Scripting (XSS), CSRF, Session Fixation and so on are typically meant to be “browser” or “DOM” driven attacks. With the changing landscape of applications, the applicability of some of these typical testing techniques and processes should also undergo some change.

Of the many apps that we(45) tested in 2016, nearly 70% of them were web-services driven architectures, that typically behaved as APIs. While these are still “web apps”, we found that the type of attacks that were successful against these apps, were very different from the ones that used to work, say even 2 years ago. For instance, we found that Access Control attacks (attacks revolving around purely authentication and authorization) based vectors contributed nearly 50% of the findings we had, compared to earlier. Client Side Attacks like XSS have lowered numbers with these apps, and they are only “functional” when the app interfaces with a browser client or mobile web view of some sort.

On the flip side, there’s a certain (wrongful) perception with companies creating these web services. Since web services is largely considered “invisible”, many organizations do not see security testing to be a major concern.This could be because they see it as a “back end service” or because they felt that a strong front-end would neutralize most attacks that would make their way to the services themselves. Chances are that your organization has a bunch of APIs or services that it hasn’t even looked at from a security testing standpoint, and that’s dangerous.

Let’s delve into 3 ways you can win with API Security Testing:

Access Control Attacks rule the roost

One of the key differences between “browser-driven” web apps and modern web services is that there is no “user interface” or navigational flow angle to the application itself. In addition, with traditional web apps, a lot of platforms delivered authentication and authorization frameworks, batteries included. However, with web services, a lot of that needs to be built in explicitly, by your architects and developers. Therein lies the challenge. We find that authentication and authorization flaws with web services are rampant as a result. Attacks from the simple – Verb Tampering to the more complex – Forging Tokens & Insecure Direct Object references (id and Mass Assignment variants) are fair game in the Web Services world.

The worst part of this is that most or nearly all of these attacks cannot be easily identified through web security scanners. There is a great deal of manual intelligence, customized fuzzing and targeted attacks that need to be directed at such apps, to uncover Access Control flaws. You need to ensure that security testing for your API and web services has a generous dose of Access Control Testing. 

Complex Stacks

The rise of web services is not an isolated event. Web Services are the result of moving to distributed architectures. And with distributed architectures, come a multitude of specialized components. Search DBs, Streaming Services, Queuing Engines, etc. to name a few. This increases the attack surface exponentially. A simple analysis of the ransomware attacks against misconfigured MongoDBs, ElasticSearch DBs and CouchDB instances should give you some idea that we have serious issues with securing the stack.

In this case, just performing an application penetration test would not suffice. I would recommend a detailed security review of various elements in the stack and the environment that it is hosted on. It is a great way of getting an inside-out and vice-versa view of the entire threat landscape.

Threat Model BEFORE the Pentest

Lack of this practice always vexes me. How do you know if the tester(s) are even addressing specific risks to your app? Most CSOs I speak to perform Threat Modeling as a static internal exercise and do not have a tactical, security tester’s view of a pentest. The best practice is to perform an Attack-driven Threat Model that captures risks, specific scenarios and attack test cases that are defined before we commence the pentest. With Web Services, this practice is all the more essential, simply because of the increased attack surface, a larger scope of threat scenarios based on the increased stack. A pre-pentest threat model also helps with correlating the model with the actual vulnerabilities identified at the end of the test.

If your pentest does not include a Attack-driven, tactical threat model before it commences, you’re really missing out!


Web Services and its more evolving avatars (micro-services and servers architectures) are the new normal. By subjecting them to no/limited/traditional application security testing, you’re probably missing out on a large section of critical vulnerabilities. These are some of the ways you can address challenges with testing API and Web Services and win with your Application Security Program.



2016 has been a year of multiple security breaches, the major instances being the Qatar National Bank breach where the attackers used SQL injection attacks to release sensitive customer information on the internet, and the ATM security breach through malware infestation affecting 3 million debit cards.

These attacks and data breaches have significantly affected companies with regard to both revenue and reputation. This has in turn led to a sharp increase in demand by end customers and regulatory bodies for companies to invest in comprehensive and periodic security assessments of applications.

However, there are several vendors providing security assessment services, and selecting the right one can be quite challenging. Here are some key considerations that will make selecting the right application security vendor a simpler process.

# 1 Threat Modeling

One of the most overlooked aspect of security assessment is threat modeling. A threat model is essentially an ‘Abuse Case’ that helps security testers view the software under test in the same light as the attackers. Security testers use threat modeling as a design analysis technique to develop innovative and effective test cases mirroring the way attackers would view the system.

CIOs and CISOs should consider threat modeling as a critical step when evaluating security assessment providers.

 # 2 Testing Methodology

It is important to assess the testing methodology employed by the vendor.  Testing methodologies such as OSSTMM and PTES are essential to gauge the effectiveness of an application security test, and product companies should consider them when evaluating vendors.  Also, keep in mind that these standards are specific to application security and should not be confused with compliances.

Information Security compliances such as ISO 27001 or PCI-DSS are overarching in nature and cover the organization as a whole from a security perspective. Compliances also demand application security assessments and mandate that assessments should be conducted under industry standard methodologies such as OSSTMM and PTES.

 # 3 Mode of Testing – Automated vs. Manual

It is essential to understand the difference between an automated and manual security assessment. The automated approach is primarily done via tools and scanners. Although this brings speed and coverage, it often lacks depth. A purely manual approach will ensure depth, but takes too long, thereby, making it impractical as it will adversely affect the application release cycle of production or go-live.

A hybrid testing approach brings the best of both worlds. Using a healthy mix of automation in the initial stages of the assessment (recon, mapping and discovery) and manual techniques in the latter half (exploitation) will ensure depth without sacrificing coverage.

In addition, effective threat modeling can further augment this approach as it will help the security tester to prioritize security risks and run custom exploits to identify deep-rooted business logic vulnerabilities that are unique to each application.

 # 4 Reporting & Analysis

Coming full circle to the final aspect – Effective Reporting. One of the primary reasons security testing goes on the back burner is due to poor reporting. Reports that provide high level description of the vulnerabilities without providing details on which page, parameter and exact steps on how to recreate the vulnerability result in developers investing a lot of time and effort on finding the flaw in the code base often without success.

It is also important to recognize that developers approach an application from a functional perspective. As a result, even when security flaws are reported, they are at a loss when it comes to fixing the vulnerabilities.

Therefore, it is critical for assessment reports to be as detailed as possible. A good report should clearly enumerate the page, parameter and how the security tester identified the vulnerability (supported by screenshots). It should also provide practical steps on how to resolve them.

 # 5 Adding Value – Building Self-Sufficiency

Although the points above talk about the key aspects that should be considered when selecting a vendor for security assessment, one should also look at value added service enhancements that can help product houses in becoming self reliant with respect to application security.

Validation of vulnerabilities (typically a bottleneck in assessments) can be optimized by automation. Creating validation scripts can greatly reduce validation iterations leading to savings on cost and effort. Scripts can also benefit developers in recreating the vulnerability on a continuous basis, thereby testing successive versions of the application for security flaws.

Training is also an aspect that is overlooked. In many cases, product organizations consider training to be optional; a good to have and not a need to have. On the contrary, periodic training when delivered in a hands-on model with relevant content that brings developers up to speed on the latest threats and exploits, will lead to overall reduction of dependency on third-party vendors for security assessments.

Happy to hear about considerations that you would’ve come across.


What triggered this article was my umpteenth email to the CTO, VP of Engineering and the Security Analyst of a leading food delivery platform. We at we45 have been trying to reach them for the past 3 months, to wilfully and responsibly disclose a full-blown security bug that our guys had researched on. I will not get into what the bug was but I can tell you this – the bug had a direct financial business impact on their operations and WILL have an impact on their top and bottom lines.

There continues to be one constant nagging voice in my head for all these months – “How does one choose to ignore such a message?” Do they think of it as a False Alarm? Do they feel awkward to accept an unintentional security bug? Are they going to make their internal security team look bad? However one looks at it – the bottom line seems to be some kind of inertia. Right? Well, before we begin pointing fingers, I tried wearing the hat of a recipient of such an email and three major thoughts crossed my mind.

The inorganic rise of consumer (mobile) applications have drawn the attention of cyber security firms worldwide. Responsible disclosure (with a capital “R”) of security vulnerabilities is a common practice and is well accepted. In fact, some run perennial Bug Bounties on their platforms. It seems quite obvious that such bounties are always a “Win-Win”. Which brings us back to the question – “Why would companies choose to go silent on such disclosures”.

  •  Aim and Fire – Security Disclosures are serious business. While companies appreciate disclosures of security loopholes, they would also prefer it to be addressed to the right audience. If you have a disclosure, don’t flaunt it. It takes just a little bit of effort to address it to the right person. Broadcasting these emails to a larger group within the company often tends to be counter-productive. Remember – never, I repeat NEVER use a language that could even remotely suggest holding the customer to ransom! That’s a road you don’t want to go down.
  • The Whole Nine Yards – This is something that I’ve heard my customers complain about a lot. Heads of Engineering or Product Development often get disclosure emails with phrases like “Found something interesting”, “Some serious issues”, “seems to be vulnerable to” etc. Such emails make them more uncomfortable than the bug itself! If you’ve actually stumbled upon something – go ahead and explain the finding with explanations or supporting evidences. Incomplete disclosure emails are often considered to be spammy or even offensive.
  •  When in Rome – It’s extremely important to speak the language of your audience. In most cases, disclosure mails are often too cryptic to decipher for a non-tech CEO and understand the seriousness or impact of the finding. While it’s important to go the whole nine-yards, it’s equally important to translate a (application) security bug into potential tangible business impact.

There really is no set formula to understand the psyche of a “victim” – however fatal the vulnerability. That said, reaching the right people, at the right time with the right tone seems to be key.