SecurityTrails Blog

SecurityTrails Blog

By SecurityTrailsTechnologyTech News
Download on the App Store

SecurityTrails Blog episodes

  • Top 5 Tips for Securing Your Dev & Test Environments, and Why You Should
    In his seminal work, The Mythical Man-Month, Frederick Brooks Jr. tells us that software development is homologous to a tar pit where many efforts flounder regardless of the appealing nature of the task or the relative tractability of the underlying physical medium. In what he calls one of the "woes of the craft", the author goes on to explain that the pervasive optimism among programmers regarding the conception of a software project is rarely maintained after we take into account the set of complex interdependencies commensurate with others' skills and objectives.
    With the understanding that security concerns are a fairly recent addition to the development lifecycle—at least to someone akin to the inherent programming paradigms of the late seventies like Dr. Brooks, one aspect remains unequivocal: programmers are commissioned with the sort of creative work that is unrelentingly attached to the pursuit of perfect usability. This is true, for example, when designing Application Programming Interfaces (APIs)—the set of exposed, intermediary function calls and routines responsible for providing high-level access to predefined software resources and applications whose latticework of dissimilar technologies can be notoriously difficult to secure.
    It is also common knowledge that to acquire even a subtle resemblance of functionality, software projects must first be anchored to an adequate test environment whereby code isolation can be properly conducted and application behavior safely observed. To the developers, these test environments usually present a number of additional advantages such as access to a broader collection of user data, or to specific backend system logs that would normally be under tighter scrutiny and more robust security controls.
    This blog post will explore some of the cyber risks associated with insecure development environments and the challenges and trade-offs that system architects must be willing to face in safeguarding them, along with some quick tips and recommendations for the road ahead.
    Risks of dev environments, and why they get hacked
    There is no doubt that test environments are a necessary evil. The very tools and applications we've all come to know and love can attribute their primordial existence to one or more of these ecosystems as they relate to the Software Development Life Cycle, SDLC.
    The staggering rate at which organizations are pushing the software development envelope, and the multitude of choices they face when it comes to hosting platforms or container alternatives, demands evermore careful planning and consideration.
    Think about iterative approaches like Agile—conceived against the backdrop of the requirement for businesses to deliver results more quickly and more safely in consumable but manageable increments. Think also of the myriad refinements, use cases, code reviews, fuzzing techniques and, more recently, chaos engineering practices modern distributed applications must endure to be deemed production-ready. None of this would be achievable, at the proper scale, without the controlled conditions that exist in a test development environment.
    That much flexibility and observability, however, comes at a price. For example, test environments are known to have less rigorous security measures and granular controls than a typical 'live' environment would—all under the aforementioned banner of agility.
    Very frequently, providing developers with this much-desired flexibility is a convoluted effort: too narrow, the privileges and programmers can be trapped in an endless barrage of access woes leading to loss of productivity and missed deadlines; too much access, and the possibility of a data breach increases dramatically. This is similar to what took place in 2018 when Shutterfly, an image sharing and printing company, warned that an employee's credentials had been leveraged by an unauthorized source to gain access to test environments storing a treasure trove of pers...
    16 min
  • Introducing ASRv2: The Next Level in Attack Surface Reduction
    After months of hard work, we're excited to announce the immediate availability of our Attack Surface Reduction tool's latest version: ASR version 2!
    Attack Surface Reduction version 2 is your best ally for exploring the Internet surface area of your organization, giving you visibility over your company's network, digital assets, and applications in a single place. Gaining visibility allows you to see the unknown—and take decisive actions to reduce the risks you face.
    **Get started for free - the attack surface report is on us!**
    With the launch of ASR version 2 we're offering you an Attack Surface Report and giving you a glimpse into our own security data **for free**. Find any security risks in your network and take action. You can expect to see:
    Your entire online infrastructure.
    A list of all of your digital assets.
    Immediate security risks.
    Web hosting intelligence.
    What benefits will you get from ASR version 2?
    Explore your digital assets
    You'll be able to spotlight all of the common hostnames related to your target. But it doesn't stop there: you can also bring up all possibly forgotten domain data, such as that related to apps, services, vpn-gateways, and more.
    Manage your inventory
    With ASR version 2 you'll have a unified view of all your discovered infrastructure data while staying advised on possible security issues, including:
    IP's pointing local.
    Remote access points with open ports.
    VPN endpoints which can be exploited if vulnerable.
    SSL certificates and their expiration status.
    Related soon-to-be expired apex domains.
    Unveil possible risks
    Get a security-wise perspective of your online infrastructure and take action to stop any security risks, such as:
    Open database ports.
    Self-signed certificates which could indicate a service misconfiguration.
    Staging or development subdomains that could mean that servers aren't properly protected, and could be compromised.
    Set custom alerts
    Your infrastructure changes, and you need to be notified as it happens. Get proactive alerts and see any unwanted configurations or changes to your infrastructure ASAP.
    Take control over your entire online infrastructure
    Stay one step ahead of the bad guys and prevent attack by gaining a new level of awareness over your attack surface with ASRv2. To test it out - grab your free attack surface report!
    3 min

About SecurityTrails Blog

From the publisher's feed

Listen to all the articles we release on our blog while commuting, while working or in bed.