Understanding other people’s problems
It’s often said that people only notice cybersecurity when it fails, or when it gets in the way of them doing their jobs. Organizations, and especially software development teams, want to be able to develop quickly and easily to stay ahead of their competition. They want to be able to embrace new technologies in an uncertain and ever-changing business world, stay ahead of your business competitors, and be the first to market with new and improved software features.
The mantra of many software development teams is to “fail fast,” a philosophy that promotes incremental development and comprehensive testing to discover if an idea has genuine business value before it is developed further. Teams want to be able to “pivot,” using an agile development environment to find what is and isn’t working and, if necessary, to quickly try something else for the best possible results. This involves concentrating on specific tasks and results, and hyper-focusing on immediate wins and fails, to move a project closer to shipping in the most efficient way for code development.
This process, known as Agile Software Development, offers increased adaptability and visibility earlier in the software product life cycle, and greatly lowers development risk and future bug-tracking volumes. It is a proven way for software teams to have insight into the products they are developing, with daily insight facilitating better communication and improved awareness of problems and issues arising from ongoing code alteration on an incremental basis.
For many application, platform, web, and software development teams, agile development is now common industry practice and offers the best route to success. It has become an essential part of the development process, and as such, our cybersecurity teams and CISOs need to be sympathetic to this and consider where they can best fit into a methodology that focuses on those people who are doing the work and how they work together, without interrupting that dynamic and while supporting the parts of the business that are creating the product as opposed to being seen (and acting as) a roadblock to development, success, and ultimately sales.
The cost of failure
Security teams are, ultimately, responsible for security, regardless of the methods of production. Development teams need that freedom to pivot and concentrate on the product, though doing so at the risk of reliability and safety can have disastrous and costly consequences.
SolarWinds is arguably now a name associated with vulnerability, rather than a major US information technology firm, and demonstrates the perils of a vulnerable software supply chain. In 2020, software updates were subtly modified by a group called Nobelium (or Cosy Bear) – reportedly directed to do so by the Russian intelligence service – then inadvertently provided by SolarWinds to users of its Orion network monitoring software. Used by thousands of worldwide organizations and government agencies, this went undetected for months – with catastrophic results on a global scale. It is known to have affected the U.S. Treasury Department, the National Telecommunications and Information Administration (NTIA), the U.S. Department of Commerce, and tens of thousands of SolarWinds customers.
Due to conflicting and competing priorities, the agile process can inadvertently fall prey to delayed patch implementation, which can leave organizations (and their users) exposed to outside attacks from bad actors and malicious third parties. In 2019, the multinational consumer credit reporting agency Equifax, headquartered in Atlanta, Georgia, was fined $575 million as a consequence of a data breach that was directly caused by a failure to patch a vulnerability. The resulting breach, which occurred over a period of several months, exposed millions of customers’ personally identifiable information (PII) – including their names, their addresses and date of birth, Social Security information, and other PII that easily could result in widespread fraud and identity theft.
While the examples may not be a direct result of a failure due to security being left out of the Agile development process, they are sobering (and very public) reminders of the consequences of software supply chain and patching vulnerabilities that can easily be the result of doing so. Ultimately, cybersecurity failure and the liability for the resulting PR fallout are considered the responsibility of the organization’s CISO and their department. As such, it is imperative this is addressed by their inclusion in the process or by the informed automation of their responsibilities – without detriment to the software production process.
Getting involved in the process
One of the downsides to the agile process is that the push towards rapid development and flexibility can often be less secure – where cybersecurity can take a back seat and the use of third-party code, to facilitate swift development, is common. In many ways, and invariably unintentionally, security can be a postscript in the push to release.
It is important for cybersecurity teams to consider this and to react accordingly. In an ideal scenario, team representatives – indeed, agile cybersecurity team specialists – should be a part of the agile development process. It may be that organizational cybersecurity teams are already using an agile (or Scrum) framework to improve the development, implementation, deployment, and management of their own internal projects. If so, there may be an opportunity to work more closely with any software development process that is using the same methodology, and the IT security Scrum Master (and, by association, their team) can be a sympathetic and ever-present participant (and consideration) in their day-to-day iterative development process.
Due to the constraints of team knowledge, frequency of daily stand-up meetings, and the disciplined but frenetic nature of agile, this is not always possible. Having a representative with access and insight into the development process is ideal, and means they can react as the development team does, but agile teams move fast, and busy IT security departments have many other areas of business operations that are competing for their attention – regardless of their own management and development processes. Cybersecurity training for software development teams is a must, but this is a specialist area and a rapidly evolving discipline – as such, training and education can often only offer a small fraction of what’s needed to keep software safe for our users.
Automation of critical cybersecurity responsibilities
IT security teams must be aware of their critical assets, their vulnerabilities, and any threats that could affect them, as part of their day-to-day practices. By default, organizations must be confident that personal data (PPI) is processed with the highest privacy protection possible to guarantee that data isn’t being made accessible to unknown parties. Regular and ongoing performance of organization-wide risk assessments should include any potential dangers from insider threats and their remediation through a permissions-based approach. Security by default and design drastically reduces potential issues from working in fast, small, but consumable increments. This consistently enforces policies and controls, meaning a reduced risk of password policy infringement, ensuring data protection regulations, and establishing a suitable third-party access policy.
Runtime protection (RASP) can be built into an application’s runtime environment and offers real-time ongoing protection from erroneous calls to third-party addresses and from potential exploitation – stopping attacks as they happen. Cost-effective, and offering supreme organization-wide peace of mind, it is especially relevant for cloud-native applications, which require far more than the default reliance on inherent perimeter security. RASP mitigates an extensive array of ever-changing attacks, injections, and weaknesses, and can be embedded into the DevOps processes by default.
Deployment of a robust web application firewall (WAF) on the edge of a network can offer automatic patching with validation and sanitization of cross-site scripting (XSS) activity, stopping injection of multiple instances of the same Cookie, mitigating SQL injection, and more, preventing the leading cause of cybersecurity breaches and safeguarding valuable data.
Cloud services offer improved agility, speed, and a secure infrastructure, but the security of data remains the responsibility of the user in a shared responsibility model. Without slowing the pace of innovation, additional cloud-native security measures can offer organization-wide peace of mind when compliance and development teams don’t have the resources to keep up with regular changes in cloud database environments. In conjunction with the other automated services above, this can afford an almost completely end-to-end automated security solution – ideal for an agile environment.
The confidence to develop
Being aware of and a part of the agile process, through hands-on or automated activities, is essential to ensuring DevOps have the confidence and freedom to do their job with the seamless support of the cybersecurity team. Communication between departments is critical, and the modern C-suite is changing to embrace this as digital security has now become everyone’s concern.
While DevOps must be cybersecurity aware, cybersecurity teams are required to be supportive and offer as few hurdles as possible for other departments in doing their jobs. While some security concessions are inevitable, and indeed essential, cybersecurity teams can still offer a part of least resistance through their own practices and through the software they use to foster organizational success. Organizations should have as much freedom as is (safely) possible to make use of new technologies, develop and add features ahead of or (in parallel with) competitors, to react quickly, and to adjust and improve in an ever-evolving and competitive software marketplace.
Try Imperva for Free
Protect your business for 30 days on Imperva.