Skip to main content

Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content.
You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Managing your cookies

Our website uses cookies. You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button.

Necessary cookies

These are essential for the user navigation and allow to give access to certain functionalities such as secured zones accesses. Without these cookies, it won’t be possible to provide the service.
Matomo on premise

Marketing cookies

These cookies are used to deliver advertisements more relevant for you, limit the number of times you see an advertisement; help measure the effectiveness of the advertising campaign; and understand people’s behavior after they view an advertisement.
Adobe Privacy policy | Marketo Privacy Policy | Pardot Privacy Policy | Oktopost Privacy Policy | MRP Privacy Policy | AccountInsight Privacy Policy | Triblio Privacy Policy

Social media cookies

These cookies are used to measure the effectiveness of social media campaigns.
LinkedIn Policy

Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Do not neglect security in development systems

Red Team Lessons Learned Series – Episode 2

Do not neglect security in development systems

 

Introduction

In this series of blog posts I wanted to highlight some common patterns of problems I observed while working in cybersecurity with various organizations. I made most of these observations while working as a Red Teamer, but there are also things that occurred to me when working as an Incident Responder. Read on to ask yourself whether your organization could be affected by any of these problems – and if so – to think what could possibly be done about it.

Development systems ARE production systems as well

During the last 10 years of my career, on many occasions I saw development and test systems’ security being neglected, most likely because they are often not seen as critical assets – as opposed to production systems.

As a result, development assets tend to get lower priority in organization’s security programs, leading to gaps and vulnerabilities in several areas, especially patch management, security monitoring and password policies.

From the offensive perspective, development systems are very high-value targets, as even though they usually do not contain production data, they provide attackers with numerous extremely potent opportunities, like:

  • extracting credentials from source code as well as from built deployment packages,
  • leveraging source code/bugtracker access to obtain information about vulnerabilities,
  • supply chain attacks,
  • extracting system and application credentials used by individual developers, to try those credentials against other systems, including production (password reuse).

 

This high potential for offensive purposes, in conjunction with weak security creates highly potent attack vectors. Poorly configured, not upgraded on regular basis and not monitored development systems usually let attackers obtain at least one working set of credentials (to a remote system/database/password reuse of a system/service/application user), that lets them move laterally without getting any attention from security teams. When development systems are easy to breach with high likelihood of avoiding detection, further advancements against production systems are very likely to stay undetected as well. It is indeed quite difficult to recognize an attack in a successful logon not being preceded with a brute force attack (especially if it happens from the same source IP address), as well as it is hard to detect a supply chain attack caused by backdoored software that came from a compromised development system.

To combat this, organizations need to start seeing development systems for what they are – they produce, and have great impact on what ends up in production systems. Additionally, a supply chain attack risk should be considered also for in-house software which is not (at the time of writing this blog) obvious. Especially since having developed something internally, organizations tend to put even more trust into it than to external vendor products. These risks can be considered even higher, taking into account that internally developed software is less likely to be digitally signed, while checksums of its files are not recognized by external security software.

You have missed the 1st episode:
“Never feel afraid to report a security incident”?

Click here to read it >>

Share this article

Follow us on