Category: Blogs

  • Leveraging the Cloud for Mainframe Access

    Leveraging the Cloud for Mainframe Access

    Now more than ever, organizations around the world are looking to extend their existing mainframe investments as part of larger digital transformation initiatives. As core systems of record and reliability, mainframes continue to run many organizations’ most important applications and the idea of replacing these systems comes with greater risk than reward. While organizations are considering modernization of their mainframe investments, it’s important to remember that maintaining mainframe access and offering new ways for their users to work with the data and systems is a vital part of the larger project.

    Leveraging the Cloud for Mainframe Access

    With the recent increase in remote work, it’s no surprise that more companies are looking to leverage the cloud for mainframe access. This has many benefits from increasing scalability, availability and performance, to reducing application costs and improving security. Implementing modern mainframe access as part of a larger cloud project ensures that an organization’s modernization journey is not only transformational but also secure.

    If making the decision to leverage the private or public cloud for mainframe access, the integration of a secure host access solution ensures teams have access to the systems and applications needed to do their jobs, wherever they may be located. Deploying this secure access in a cloud environment is made easier by host access administration being integrated and centralized with the corporate user directory. Along with simplifying provisioning and management, centrally managed host access is, most importantly, more secure than other forms of access.

    The extension of enterprise security to the mainframe is sometimes overlooked in a transformation, but it is an integral part of the larger process of strengthening data and system security. In a perfect world, this can best be done through the integration of a host access solution with the existing identity and access management (IAM) system. If this is possible, the authentication credentials that are already in use for authorizing or denying access to the mainframe can be leveraged successfully.

    There are numerous benefits to an IAM integration with regard to access, data, stronger passwords, application security settings and system configurations. With IAM, the benefit of least privilege access means that users can access only the mainframe systems and data that are needed to do their jobs. Additionally, application security settings and session configurations can be changed from a central point by using the user directory. Finally, the stronger credential requirements of the IAM integration get rid of weaker eight-character passwords, strengthening security as a whole.

    Host Access Improves User Experience

    When it comes to host access, having a secure and centralized solution not only improves the mainframe access experience for the user, but also for the administrator. With zero-footprint secure access, users can be moved to a more secure web with higher security standards if needed. Security is also stronger with enterprise credentials that leverage mainframe session authorization to automatically sign them in. The integration of a host access solution gives administrators the ability to quickly deploy secure browser-based sessions, as well as providing web interfaces with no Java required, eliminating workstation dependencies as a result. This is also paired with the use of containers to enable deployment to countless users and support for mobile devices. For these reasons, a host access solution should be a common component in any cloud journey.

    The mainframe and its data, applications and user access remain vital for organizations and it is important that they remain protected and connected. With security being an ever-evolving issue, keeping these core systems secure while ensuring employees are able to access the systems and data they need should always be a priority. In conclusion, organizations looking to leverage the public or private cloud for their mainframe will have more success if they also strengthen their data and system security as part of the process.

  • Continuous Testing Practices Gap Assessment

    Continuous Testing Practices Gap Assessment

    Continuous testing is an essential part of DevOps. To get the maximum value from continuous testing, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevOps and determine a strategy for improvement. Gap analysis provides valuable input for formulating a strategy and a roadmap to improve continuous testing.

    My SlideShare, Gap Survey, Assessment and Analysis For Continuous Testing, explains how my continuous testing gap assessment tool greatly speeds up the gap survey, gap assessment and gap analysis process for continuous testing.

    It is important to clarify a few definitions for this blog because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions.

    • Gap survey is a discovery tool used to collect information about the current state of practices for a topic such as continuous testing.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    I define and use a seven-step process for gap assessments.

    The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic, such as continuous testing.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as continuous testing, will normally be fairly complex with tens if not hundreds of practices. Categorize the practices into groups (I call the groups “pillars”) to make the list of practices more understandable and meaningful. To do this requires some research and discovery work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE as well as some other topics.
    3. Enter the practices from step two into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    For the remainder of this blog, I will explain in detail the seven steps for continuous testing.

    Step One: Pick a Topic to Analyze

    In this blog, the topic is continuous testing.

    Step Two: Determine Recommended Practices for Continuous Testing

    For an example continuous testing assessment, I used the 15 practices categories described in this three-part series:
    Continuous Testing Practices Part 1
    Continuous Testing Practices Part 2
    Continuous Testing Practices Part 3

    The 15 practice category pillars are:

    • Continuous testing tenets
    • Leadership
    • Culture
    • Test strategy and plans
    • Test management
    • Test automation
    • Test tools
    • Test infrastructure management
    • Test scripts
    • Test results
    • Security tests
    • Pre-flight testing
    • Integration testing
    • Pre-production testing
    • Test in production

    Step Three: Enter the Practices from Step Two Into a Gap Assessment Tool

    A gap assessment tool, pre-loaded with sample continuous testing practices, can be found in a file called “Continuous Test Practices Assessment Tool v2. It can be downloaded for free from one of the resource pages found on my website Engineering DevOps.

    You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step Four: Determine Who to Include in the Gap Survey

    For the gap analysis to be comprehensive, people in roles that are affected by continuous testing practices need to be surveyed, or at least represented, to ensure their perspectives are included. The following are example roles that typically are included.

    • Business leaders – because they influence culture and budgets for continuous testing.
    • Developers – because they need to design in accordance with continuous testing practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with continuous testing practices.
    • Ops – because continuous testing practices affect operations.
    • Security – because continuous testing affects security practices.

    The survey can be conducted for an individual application, a group of applications, or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organizational segment that is being targeted for improvement.

    Step Five: Collect Data Using the Gap Survey

    A gap survey should allow each surveyed person to enter an importance level score, a practice level score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included within my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=Not relevant, 1=not Important, 2=Nice to have, 3=Important, 4=Very important or 5=Critical. Practice level choices are 0=Not sure, 1=Rarely, if ever, 2= Sometimes, 3=Most of the time, 4=Always or 5=We are really good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step Six: Perform a Gap Assessment

    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step Seven: Perform a Gap Analysis

    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories determined by a consultant or topic expert. The results of the gap analysis indicate where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    Those who are serious about DevOps will do well to learn from others and be serious about using recommended continuous testing practices. This blog explained a gap assessment approach, which uses my 15 categories of continuous testing practices. My free Continuous Testing Gap Assessment Tool facilitates performing a gap analysis for continuous testing and outlines priorities to improve DevOps practices for an organization. For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

  • No More Status Quo: Disruption and Reinvention through The Entrepreneur’s Weekly Nietzsche

    No More Status Quo: Disruption and Reinvention through The Entrepreneur’s Weekly Nietzsche

    Everyday we’re reinventing ourselves. Whether we’re reinventing knowledge through learning, or technology through development, nothing stays stagnant and disruption makes sure of that.

    In a TechStrong TV segment, MediaOps Co-Founder and Editor-in-Chief Alan Shimel sits down with Brad Feld, current managing director at Foundry Group and author of “The Entrepreneur’s Weekly Nietzsche: A Book for Disruptors” to discuss this reinvention and the importance of disruptors. 

    If you’re not familiar with Brad Feld, he’s a well known venture capitalist and author who’s had his hand in the startup community as an author and founder of TechStars, a capital market company. He teamed up with Dave Jilk, a former partner of Feld Technologies, Brad’s very first company. 

    To cycle back to the word “disruptor,” it’s one Brad wants you to hang on to. He says, “Anybody who is involved in being a disruptor of an industry whether you’re a founder or a leader or an employee of a company, we like to think this is applicable to what you’re doing.” 

    Because of their focus on disruptors, it’s only fitting that Brad and Dave chose to concentrate on one of the most disruptive philosopher’s in history: Friedrich Nietzche. As Brad says, “In the 1860s to the 1890s, when he wrote the body of his work, Nietzsche was very disruptive to the status quo – of everything.” Like Nietzche, if you’re an entrepreneur or in the tech community today, you’re challenging conformity and reinventing the world.

    While this book is intended for entrepreneurs, you certainly don’t have to be one to enjoy this book. “Entrepreneurial thinking is valuable for everybody in all aspects of life. Doesn’t mean you have to be an entrepreneur but the kind of mindset of an entrepreneur is powerful to understand,” says Feld. If you’re a disruptor, or simply enjoy learning, you’ll get a lot from this book.

    And if you’re worried about not understanding the philosophy component, fear not. “The Entrepreneur’s Weekly Nietzsche: A Book for Disruptors” is incredibly accessible. Brad uses very small quotes (one to three sentences) from Nietzsche and translates it into contemporary English. After each quote is a short essay intended to “provoke thought, not tell you the answer.” As Brad says, “One of the meta goals of this book is not to tell people what to do. It’s to stimulate thinking.”

    As a bonus to most quotes and essays, there’s actually a narrative written by an entrepreneur (some famous, some not-so-famous) discussing their experience and what they thought of when Brad and Dave gave them the quote. 

    With 52 different topics, this book is not meant to be gobbled down. While you can, you’ll get a lot more out of it when you dip-in and dip-out of areas that you’re interested in. Feld and Jilk’s hope is to simply get people to think: “We’re trying to help people stimulate thought around these ideas. Presumably any one of these topics is something you can ponder and meditate on.”

    “The Entrepreneur’s Weekly Nietzsche” isn’t an untouchable academic piece, rather a relatable reflection of the human experience. Talking about the importance of including his own experience in the book, Brad emphasizes, “I don’t write books for a living. I’m a venture capitalist for a living. I write books because I love to write, I love to read and I love to think. My motivation for the writing is part of my own experience learning.” 

    Whether you choose to read a chapter a week or every few weeks, Brad and Alan recommend you take each chapter on its own. Think about it and internalize it before moving on. And if you’re able to re-read chapters, that’s even better. “Today, what I find myself doing when I do these talks is I’m reading these quotes again and I’m discovering new things in the quotes and what they make me think,” says Brad. “Again, not trying to tell me the absolute truth from the quote, but the thought that it then stimulates.”

    If you’re into learning, disrupting or the entrepreneurial mindset, check out “The Entrepreneur’s Weekly Nietzsche: A Book for Disruptors” and attend Brad’s session at TechStrong Con 2021 Virtual Summit, on June 14, to enter his book giveaway.

  • Managing Cloud Governance Costs Collaboratively

    Managing Cloud Governance Costs Collaboratively

    For those responsible for managing infrastructure, the concept of governance is common, especially as it relates to cloud services. For cloud services, it’s defined as a framework that guides how end users use these services by defining and creating policies to control costs, minimize security risks, improve efficiency and accelerate deployment.

    The term is often associated with “rules” or “compliance” and can restrain innovation within an organization, as it typically is mixed with regulatory bodies and governance procedures that add cycles to required tasks. But what if we could flip the script and make governance more of a collaborative effort? What if we used an approach wherein teams across an organization share information and feedback for better business outcomes?

    This collaborative approach can be beneficial in ensuring everyone is on the same page, enabling businesses to get the most out of their cloud infrastructure while ensuring costs stay within budgets.

    Legacy Governance Overshadows Growth and Creativity

    Legacy governance is an extremely paranoid way of running your business. For example, blocking people or departments from making buying decisions is a perceived best practice to avoid overspending on cloud infrastructure. Unfortunately, this is actually the opposite of what organizations with cloud infrastructure should do.

    The advantage of the cloud is that it gives your organization the ability to develop and bring products to market faster—and at a lower price point—than traditional methods. Following legacy governance processes—adding more steps to the process for provisioning resources—results in slower launch times and overprovisioning of resources (since there is a lack of visibility and teams are not sure when they will get more), negating the cost benefits of on-demand cloud infrastructure over traditional data centers.

    Empowered Employees Produce the Best Results

    Think about it: An overbearing manager or boss makes you feel like you’re walking on eggshells when it comes to your work. Sometimes, this is the same effect legacy governance policies can have on employees.

    Removing access barriers and giving team members the freedom to easily request and use resources should be a cloud operator’s ultimate ambition. It’s also cost management that’s collaborative.

    The idea behind a collaborative approach to managing costs is that the individuals who work on the projects themselves–whether that is the engineering team, DevOps teams, etc.–are best suited to manage them and provide the proper infrastructure recommendations because they know what their needs are.

    To receive the full financial and organizational benefits from a collaborative approach, there are three simple steps to take:

    Have a Consistent Source of Truth

    Have a consistent and agreed-upon source of truth for decision-making and self-evaluation against key metrics. This means that everyone in the business—executives, finance, managers and individual contributors—are aligned and looking at the same numbers. When this happens, teams spend less time haggling about ownership and more time looking at how they can improve. When this doesn’t happen, the focus turns to storytelling about why the numbers are wrong, not solving the underlying inefficiency problem.

    Trust the Team

    Trust the members of your organization to leverage this information for the best possible business outcomes.

    Collaborate

    Encourage collaboration inside and between layers of the business to ensure the decisions are made with the complete picture in mind.

    Implicit tradeoffs are made every day at every business level for teams to align their work to organizational priorities. Encouraging collaboration between different layers, viewpoints and skillsets in the business helps to highlight these implicit decisions and make them explicit, intentional and agreed-upon

    Moving away from legacy governance to a more collaborative approach is within reach for any organization. The key is understanding what methods are required for the transition to be a seamless and positive experience that teams will embrace.

  • The Forces Massing Against the Data Center

    The Forces Massing Against the Data Center

    We’ve come a long way over the last few decades. A ton of stuff about IT has changed, even in the last five years. And it is true in IT that the only constant is change.

    We like to have control of our environment to provide the most stable platform for user satisfaction that we can and simplify troubleshooting when things do go wrong. But even such a simple desire has been stripped away in the flood of changes we face. To be certain, some areas of IT within most enterprises are very stable environments that only change after careful consideration, but much of the rest of IT–both within and outside of the enterprise–has become the wild west again.

    And there is a lot of good in this cycle. Trying new things solves old problems and drives innovation, there can be no doubt. The changes we’re making address things like, “There was never enough testing,” or “We don’t have the security staff,” which means our apps are better because of the wave of changes we’re currently riding. The cloud is a standard option for new development even in the most stodgy enterprises, and some enterprises are moving older apps to the cloud as time permits.

    That last bit is going to force some hard choices in the future. As many of you know, I spent several years writing exclusively about storage, so when I see something happening in the storage space, I get interested. A former coworker of mine recently wrote about Kubernetes storage options from an angle I hadn’t considered before, and it drove me to look deeper into what’s going on today.

    In case you missed it, storage–specifically, data gravity–has tethered a large number of applications to enterprise data centers. The app needs access to the data; if the data is in the data center, the app has to be there and have secure, ready access to the data somehow. Cloud and containers offered some options/workarounds to deal with this issue, but they’ve lagged far behind the rest of the agile infrastructure.

    That is changing. Higher-speed, distributed datasets are here and are being used. I have not followed the space closely, but my immediate thought is, “They have to be proven.” They’re going to have to show that they’re as stable and secure as the DBMS in the data center and that you can get your data out of them no matter what. In the end, data is a company resource–a very valuable company resource. In some cases, the data a company owns is worth more than the company’s products. So, total control and security of that data is imperative and must be proven on the ground.

    But it will be. Because there is a need. And that will be the final step in making data centers far less critical for the average enterprise. Some enterprises already don’t need a data center, but most still do, largely because of data control and the resulting data gravity. Apps can be shifted from cloud to cloud or cloud to on-premises, or from cloud to hosting via Kubernetes, almost as an afterthought. But data is far less agile. In the end, a couple terabytes (or petabytes, depending on dataset) of data aren’t just flung over to a new cloud. Distributed, though; copies could be done in parallel, at high speed, making them far more mobile.

    Vendors already recognize that subscription models are easier to sell, with far fewer user maintenance headaches. IT enjoys not having to go through huge checklists to make sure every bit of supporting software is up-to-date with the right version–in a hosted environment, it’s done for you. Enterprises already recognize that a fair number of applications can be cloud-native and are putting them out there. Slowly, over time, more and more applications–even data-heavy applications–will be viable in the cloud for your average organization. The bottleneck, as I see it, will be cloud storage costs. Cloud storage is both more cryptic than other cloud costs and more expensive. Ingress, egress, storage, instance … all these things add up, and the more instances required to achieve parallelism, the more they cost. Until that issue is resolved, don’t expect any mass migrations. But migrations will come, eventually. Kubernetes is preparing to do its part and make data easier to use and move; cloud vendors will just have to find a way to rationalize the bandwidth implications with the costs we, the users, are charged.

    But over time, it will be less profitable to produce hardware and software targeted at individual enterprises. We’ve already seen some moves to hosted models that should open your eyes to the direction your vendors are headed–Atlassian and pretty much the entire source code scanning industry, for example, come to mind.

    For most organizations that have been around awhile, the key to making the move will come from internal motivations. They’ll have to figure out how to manage containers with virtual storage internally, in their data center, before they’re comfortable throwing that architecture out onto the public cloud. It’s a good path, but for the short to mid-term, data gravity will slow or even halt the “To The Cloud!” charge for core applications.

    For most large and established organizations, the ROI just isn’t there to move tons of data around. The core systems that work will be kept and may be improved, and only when they need to be replaced will things like a full-on container architecture be considered. But, again, this is likely to be an internal architecture, to start, (and often, will be forever) simply because that’s where the important data is.

    For newer organizations, the opposite will be true for the short to mid-term. As the data lake grows in the cloud, the costs to keep it there grow in a non-linear fashion, eventually biting into profitability. This group will also want to understand how to run a fully agile container infrastructure internally, complete with virtual data access.

    Whichever group you belong to, consider adding on-site Kubernetes or local cloud skills to your talent repertoire. Those are the skills that overlap; the juncture where all of these paths seem to cross, and the agility that full-on container automation with storage offers will not negatively impact the organization.

    And keep rocking it. We’re enjoying your apps. Thank you for keeping them humming along!

  • Applitools Extends Visual AI Testing to Native Mobile Apps

    Applitools Extends Visual AI Testing to Native Mobile Apps

    At its online Future of Testing: Mobile event, Applitools today previewed the ability to apply visual artificial intelligence (AI) to applications that run natively on a mobile computing platform.

    Accessed via a cloud service that is currently available for free on a limited basis, the Ultrafast Test Cloud for Native Mobile offering will extend the company’s visual AI tool for browser-based mobile applications to applications that run natively on Apple iOS or Google Android devices.

    Applitools CEO Gil Sever said that while most mobile enterprise applications today rely on browsers to make it simpler to build and deploy applications, in time, many more of these applications will be running natively on iOS or Google Android platforms, mainly because they provide a better user experience.

    That approach also eliminates the need to rely on cumbersome platform emulators to test applications because the Applitools AI tool can learn the nuances of each platform in a way that streamlines the application testing process.

    In fact, visual AI tools will not only make developers and testing teams more efficient, but they also will make it easier for end users to participate in the application testing process, Sever noted.

    The Applitools approach to AI testing also provides developers with more control based on the application’s use cases. Different settings can be applied to test, for example, a medical application that requires perfect alignment of pixels versus an e-commerce application that may not require as much fidelity. Developers can then resolve regression issues by employing root cause analytics.

    It’s not clear how broadly visual AI tools that use computer vision algorithms to automate testing will be employed. There is no doubt the current pace of application development is faster than most dedicated teams of testers can handle. As a result, more responsibility for application testing is being shifted left toward developers that, in the interest of time, might be more inclined to rely on AI and other forms of automation that can be accessed via a cloud service.

    The rise of AI testing tools might also go a long way toward ensuring more applications are thoroughly tested before being deployed in a production environment. One of the first steps in any application development schedule that gets compressed when a project falls behind schedule is testing. As more rote tests are automated, there should be more opportunities for dedicated testing teams to focus on improving the end user experience.

    It may be some time before most organizations are routinely employing AI to test applications. However, none of those organizations should expect AI to replace the need for humans to test applications alongside AI testing platforms that can see the actual application. After all, there’s a world of difference between seeing the changes that were made to an application and understanding why they actually needed to be made.

  • Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue today unveiled a 1.0 release for Regula, an open source policy engine for infrastructure-as-code (IaC) security that comes with prebuilt libraries for implementing hundreds of policies that validate configurations on Amazon Web Services (AWS), Microsoft Azure and Google Cloud services.

    Regula is based on the Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is compatible with both Terraform and AWS CloudFormation tools for configuring cloud infrastructure.

    Developers can also build custom rules on top of OPA using libraries that Fugue created for the Rego programing language that is part of the OPA specification. Regula supports output formats such as JUnit, Test Anything Protocol (TAP) and JSON to make it easier to integrate Regula with other tools and frameworks that make up a DevOps workflow. Input formats supported include Terraform HCL, Terraform plan JSON, AWS CloudFormation and Serverless Application Model templates.

    Regula also provides out-of-the-box support for the CIS Foundations Benchmarks in addition to other policies defined by Fugue, such as dangerously permissive identity access management (IAM) policies, Lambda function policies allowing global access, volumes with encryption disabled and untagged cloud resources.

    It is deployed as a pre-packaged binary that includes a command line interface (CLI) through which Regula can be incorporated within a DevOps workflow and can be installed using tools such as Homebrew or deployed as a Docker image.

    Fugue CEO Josh Stella said Regula provides DevOps teams with an extensive library of rules that check for common security and compliance violations as well as advanced multi-resource misconfigurations. That latter issue is especially challenging because developers typically don’t have much visibility into dependencies that can inadvertently provide cybercriminals with access to, for example, an S3 cloud storage bucket that otherwise appears to be configured properly. Regula will also identify any required resources that might be missing, as well, added Stella.

    Stella said Regula 1.0 provides a simpler approach to securing cloud infrastructure. Cloud infrastructure is frequently misconfigured simply because a developer made a mistake. Unfortunately, cybercriminals have become especially adept at scanning cloud platforms for these misconfigurations, noted Stella.

    It’s not clear to what degree a backlash might be building against IaC in the wake of recent high-profile breaches of software supply chains. Organizations have embraced IaC tools to make developers more productive. However, each security incident involving a misconfiguration of cloud infrastructure resources makes it all too apparent that developers lack the expertise required to securely provision IT environments. Rather than creating a series of cybersecurity reviews that would reduce developer productivity, Stella said Fugue is making a case for a compliance-as-code approach that developers can readily understand and implement.

    One way or another, cloud infrastructure has to become more secure. Business leaders are growing weary of security incidents that, from their perspective, are caused by careless mistakes. Their first instinct is to empower cybersecurity teams to resolve those issues once and for all. The only issue that needs to be resolved now is just how cumbersome those security reviews need to be if developers are provided with the tooling required to secure cloud platforms themselves.

  • JFrog Acquires Vdoo to Advance DevSecOps

    JFrog Acquires Vdoo to Advance DevSecOps

    JFrog today announced it has agreed to acquire Vdoo for $300 million in cash to gain a set of analytics tools that discover vulnerabilities in application binaries.

    Vdoo’s scanning tools, infused with machine learning algorithms, will be fully integrated with the JFrog Xray vulnerability detection tools along with the rest of the JFrog continuous integration/continuous delivery (CI/CD) platform in 2022. In the meantime, the Vdoo scanning tool will continue to be made available via a software-as-a-service (SaaS) platform that Vdoo built.

    The Vdoo platform is already integrated with the JFrog Artifactory repository and JFrog Pipelines. Vdoo’s platform also is integrated with DockerHub, Jenkins, GitHub, GitLab and Azure Pipelines via REST application programming interfaces (APIs) that make the Vdoo scanning tools accessible via a command line interface (CLI).

    JFrog CTO Yoav Landman said acquiring Vdoo is critical because when it comes to implementing DevSecOps best practices, the only meaningful place to discover and remediate vulnerabilities is in the binaries deployed in production environments. As such, the Vdoo platform provides a superior alternative to both static application security testing (SAST) and dynamic application security testing (DAST) tools that scan for vulnerabilities in source code, added Landman.

    Developers require accurate intelligence that can be quickly acted upon to secure applications running in production. They can quickly take action once they know how a specific vulnerability impacts a binary, versus being told to update source code that could take days or weeks to complete, noted Landman. The Vdoo platform also makes it possible to leverage machine learning algorithms to detect zero-day vulnerabilities, malware, exploits, backdoors, supply chain risks and other threats before they become commonly known. Those vulnerabilities can be detected in everything from application binaries to firmware running on embedded devices. Vdoo is also recognized by the Mitre Corp. that oversees the Common Vulnerabilities and Exposures (CVE) database as a CVE Numbering Authority (CNA) for discovering vulnerabilities.

    JFrog Vdoo

    As responsibility for application security continues to shift left toward developers, many organizations are finding the tools that cybersecurity teams employed to discover threats don’t lend themselves to the workflows that developers have created to build applications. As a result, many of these tools are being replaced by developer-friendly alternatives that developers can invoke via a CLI as part of DevOps workflow. The goal, now, needs to be reducing the level of noise created by security tools to enable developers to focus on the vulnerabilities that specifically impact their code, noted Landman. Otherwise, developers are simply overwhelmed by a massive number of alerts generated by security tools that often don’t appear to be especially relevant, Landman added.

    It’s not clear how quickly responsibility for application security is shifting left. However, in the wake of a series of high-profile software supply chain breaches, the urgency surrounding adoption of DevSecOps best practices has increased considerably. The challenge, as always, is getting the right tools into the hands of developers at the right time.

  • Best Practices for Cloud Incident Response

    Best Practices for Cloud Incident Response

    Cloud computing is now mainstream, with almost all organizations running at least some resources in the public cloud—whether software-as-a-service (SaaS), platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS). Security teams have been scrambling to adapt to cloud environments, and with the growing adoption of DevSecOps, they are working together with DevOps teams to secure cloud systems from the ground up.

    As your organization discovers the best way to secure its cloud investments, you also need to develop an incident response strategy for the cloud. Even if your cloud security controls are perfect (and they aren’t), attacks will happen. Knowing what to do during an attack and preparing teams for incident response can be the difference between an incident quickly contained and resolved, and a multimillion dollar disaster.

    What Is Incident Response?

    Incident response enables organizations to make sure they are aware of security incidents and can respond in time to limit the damage to their systems. The objective is to block attacks and prevent similar attacks in the future.

    The SANS Institute’s six-step incident response process provides a structured framework for security incidents. These steps are:

    Prepare—establish security policies, carry out risk assessments, determine which assets are sensitive and establish an incident response team.
    Identify—monitor your systems to detect anomalous activity, identify real security incidents and investigate the severity and type of threats.
    Contain—conduct short-term containment procedures to stop the spread of the threat, followed by long-term containment, such as applying temporary fixes and rerunning a clean system.
    Eradicate—identify the root cause of the incident, remove malware and implement measures to prevent future attacks.
    Recover—restore your production systems and apply measures for preventing further attacks. Test and monitor recovered systems.
    Learn—perform retrospective analysis within two weeks of the incident with complete documentation evaluating containment efforts and determine how you can improve the incident response process.

    How to Prepare Your Cloud for Incident Response

    There are several ways you can prepare your incident response team and your cloud environment for more effective incident response:

    Establish response goals—determine incident response objectives in consultation with stakeholders, legal advisors and organizational leaders. Common goals include problem control and mitigation, restoration of affected resources, and storage of data for evidence and attribution.
    Use the cloud to respond—ensure your cloud resources include the tools and resources you need to respond to an incident. For example, ensure you have robust cloud-based logging and monitoring systems, and set up cloud-based backup and disaster recovery so you can rapidly restore affected systems.
    Determine your requirements—keep copies of logs, snapshots and other evidence in a centralized cloud account. Apply mechanisms to enforce retention policies. Use tags and metadata to maintain visibility and connect logs and cloud resources to organizational units, projects or corporate systems.
    Use a redeployment mechanism—if a security anomaly is caused by a misconfiguration, you should be able to remediate it easily by redeploying the resource with the appropriate configuration. Ensure the response mechanisms can be executed multiple times if necessary.
    Leverage automation—after identifying recurring problems and incidents, automate as much as possible and break them down programmatically to build response mechanisms for common situations. For example, use the mature auto scaling service on AWS or Microsoft Azure’s infrastructure-as-code (IaC) capabilities. This is much easier on the cloud than it was in an on-premises data center. Ensure you use human response only for unique, new or critical incidents.

    Effective Incident Response in the Cloud

    Use the following tips to improve your ability to respond to security incidents in a public cloud environment.

    Shift Your Focus

    Cloud environments require you to monitor different elements than you would in traditional on-premises environments. In the cloud, you should focus on applications, APIs and user roles. Consider how incident responders can operate successfully in a cloud environment, and what tasks they may need to perform. The incident response team must have proper access and visibility into your systems so they can detect, remediate and prevent attacks.

    Integrate Alerting and Incident Management Tools

    The security team must have direct access to supporting data to triage alerts and classify incidents. To this end, security alerting tools should be integrated with any incident management tools you use, like PagerDuty and Slack, for example. This enables security alerts to directly reach the existing tools and workflows used by your teams. Responders won’t have to alternate between tools to see what is happening.

    Build an audit trail to capture the response to each alert, which will provide visibility and accountability and help you refine your response processes. All actions taken in security tools must be visible in the relevant collaboration tool, so you can see who dismissed a specific alert and when, and what annotations they made.

    Work with Your Cloud Provider

    Cloud providers usually have an incident response team, but you cannot assume the vendor will handle everything during an event. Be aware of the shared responsibility model, where cloud providers are responsible for securing the infrastructure, while the customer is responsible for data and workloads.

    Make sure you understand the service agreement for your cloud provider and who is responsible for exactly which element of the response. Find out exactly what alerts you can expect from the vendor’s team and how it can support your own team. Having a clear relationship and establishing points of contact can save critical time during an incident.

    Protect Your Logs

    The major cloud vendors provide logging capabilities for their environments, including log files or operational metrics to provide insight into service operations. Logging services may be free or paid, ranging from basic access logs to complete audit and configuration logs. Most cloud logging service will allow you to store logs outside the cloud or on-premises—and it is critical to do so.

    Logs are a useful resource for incident response investigation, and you must ensure they remain inaccessible to attackers. An attacker might be able to compromise your cloud system or services, but they won’t be able to modify or delete your logs. Logs are a protected source of information that can help you identify the attack timeline, targeted systems and the attacker’s IP address. This provides a reliable starting point for investigations.

    Conduct Cyber Range Training

    Organizations often rely on exercises to train or test their security and incident response capabilities. Today, cloud environments provide an opportunity to simulate your production network in a protected environment, allowing your security team to practice their response to real attacks on your network within a safe setting.

    Tools such as AWS CloudFormation allow you to quickly design and deploy training networks that are identical to your actual network. You can keep costs down by limiting the duration of exercises. These exercises may be the best way to prepare your team to respond to attacks in the real world.

    These are the basics of security incident response, preparing a cloud environment for incident response and how teams can effectively react when the inevitable attack occurs. In short, it’s important to:

    Focus on what matters – In the cloud, this is APIs, applications, and identity and access management (IAM) systems.
    Integrate alerting and incident management tools – The cloud provides ample automation capabilities. Use them to respond automatically to common anomalies.
    Work with your cloud provider – You are not alone in the cloud, and teams need to understand exactly which part cloud providers will take in responding to an incident.
    Protect your logs – If logs are exposed to tampering, you will have no way to detect, investigate and respond to attacks. Protect them at all costs.
    Conduct cyber range training – You’ll never really know what it’s like to respond to an incident until one actually happens. Instead of waiting for a real attack, conduct a “cyber range training” or security drill and see how everyone works together in an attack scenario.

    Now, you’ll be better prepared as you move towards a cohesive cloud security strategy for developers, operations, and security teams.