Tag: asset management

  • Overcoming Cloud Asset Management Challenges

    Overcoming Cloud Asset Management Challenges

    Twenty years ago, no one in IT could have predicted the monumental role that cloud computing would play in our everyday lives. To play off the words of Back to the Future‘s Doc Brown: “On-premises? Where we’re going, we don’t need on-premises.” As technology continues to evolve, though, security teams face greater challenges.

    Infrastructure is no longer server rooms and boxes; it is dynamic, changing constantly to support fluctuations in demand. And moving to the cloud introduces new third parties into the digital mix. Although AWS, Google, and other cloud providers have a lot at stake when it comes to protecting customer data, security responsibility is never completely out of an organization’s hands. Compliance considerations are yet another complicating factor. In many cases, regulations around data access, privacy and residence were created for an on-premises world.

    Looking to the future, companies want to maximize their investments in the cloud, while better addressing these security challenges. However, the rapidly changing nature of the cloud makes it difficult for security teams to fully understand the scope of assets they are responsible for at any given point in time, which is an absolute necessity in order for companies to truly be secure. After all, how can a company make sure it has no gaps in its cloud security if it can’t account for all cloud assets – especially when working with multiple cloud providers?

    Security teams need to inventory their entire cloud infrastructure, understand what controls are in place and find ways to detect and mitigate any vulnerabilities or misconfigurations in a timely manner.

    Understanding Cloud Workloads

    When moving assets to the cloud, it can be incredibly difficult to try to inventory devices with dynamic IP addresses, which constantly change, compared with more static devices. The mass adoption of containers and microservices, some of which exist for just seconds before disappearing, make dynamic systems even harder to track.

    One of the most important improvements that have come out of cloud growth is that everything has an API, which can be a massive advantage when inventorying assets. Because each cloud provider is self-contained, finding out when a new bucket or instance is created is certainly possible. Organizations that have advanced development capabilities can write and maintain their own applications to identify every new cloud instance for each provider – but doing this for multiple cloud providers and correlating cloud asset inventories with other security control data becomes a major investment of resources. The ability to access all resources in the cloud makes asset management a more achievable goal.

    Security Controls

    It is essential for organizations to carefully manage their assets and understand the security controls in place to know exactly what they cover. By categorizing their resources, companies not only better understand what they have, but can make informed decisions about exactly what additional security measures need to be taken. For example, vulnerability scanners may not be scanning critical workloads – or perhaps dedicated cloud workload protection platforms need to be deployed for certain cloud assets. It can be incredibly difficult for security systems to keep up; since cloud assets can be created so quickly, they need security systems tailored specifically to keeping them safe.

    A security tool can only secure devices that it knows exist. Once an organization understands the assets it has, it can expand the coverage of any existing tools to devices that were previously unknown. When that coverage is fully adopted, asset management can help the organization find gaps in its coverage to identify areas for additional protection and the right tools to secure them.

    Addressing Vulnerabilities and Misconfigurations

    Once an organization establishes a comprehensive asset inventory and visibility, the next step is to address vulnerabilities, gaps in coverage or misconfigurations that are found. With the ability to spin cloud instances up or down at will, it is inevitable that instances may be forgotten and inadvertantly left unprotected. Since cybercriminals automatically scan public cloud infrastructure to exploit these types of vulnerabilities, public-facing cloud workloads are especially at risk.

    Similarly, finding and addressing misconfigurations in cloud workloads becomes more complex. With the highly configurable nature of the cloud, mistakes happen often, and without proper security controls in place to detect these misconfigurations, attackers can easily access and steal data. Organizations must implement a process to continuously detect cloud workload misconfigurations.

    A great place to start is the Center for Internet Security (CIS) Benchmarks, which provides objective security guidelines. By comparing data from each cloud provider with the rules in the CIS Benchmarks, security teams will be able to identify assets that don’t adhere to best practices.

    The key to maintaining security in a modern cloud environment is to implement continuous discovery and interrogation, which requires automation. This includes the ability to create tailored alerts when certain conditions are met, and automatically deploy and change security controls as needed. Teams should set restrictive access controls by default so that non-approved users don’t have access to sensitive data. Any time a cloud workload deviates from policy, there should be a plan in place to automate the corrective action.

    Computing technologies continue to evolve at a staggering pace. The computing environment 20 years from now won’t resemble even the most far-fetched, futuristic ideas today. The evolution of cloud adoption from justified skepticism to ubiquity taught us an important lesson: change is constant. It is incumbent upon technology and security professionals to  constantly challenge the expectations of security solution coverage and adherence to controls to keep data and systems protected.

  • Atlassian Adds Asset Management to ITSM Portfolio

    Atlassian Adds Asset Management to ITSM Portfolio

    Atlassian this week announced it has acquired Mindville, a provider of IT asset management software that the company plans to integrate with its Jira ServiceDesk platform.

    Edwin Wong, head of product for IT at Atlassian, said Mindville will extend the reach of its IT service management (ITSM) portfolio, which includes Opsgenie for incident management, Jira for project management and the recently acquired Halp software for conversational ticketing.

    Mindville, which already makes its software available on the Atlassian marketplace, has more than 1,000 customers including NASA, Spotify and Samsung. The acquisition of Mindville presents an opportunity for those IT teams to manage IT assets within the Jira ServiceDesk platform, which is widely employed as a help desk to manage interactions with end users, said Wong.

    Atlassian has been steadily bolstering its ITSM portfolio at a time when competition across the sector is fierce. In the wake of the COVID-19 pandemic, many IT organizations are re-evaluating their IT help desk platforms now that it has become apparent many employees will be working from home much more regularly.

    At the same time, IT organizations are looking to reduce the total cost of IT, which becomes easier to achieve if they acquire all their ITSM tools from a single vendor. Going forward, Wong said IT teams should expect Atlassian to continue to tighten integration across both its ITSM and DevOps tools portfolio. The goal is not so much to converge every offering into a single platform as much as it is to seamlessly share data between all the tools that make up that portfolio, he said.

    Atlassian this week disclosed it generated $1.6 billion in revenue for the fiscal year, a 33% increase over the prior year. Total revenue was $430.5 million for the fourth quarter of fiscal 2020, up 29% from $334.6 million for the fourth quarter of fiscal 2019. Atlassian ended the fourth quarter of fiscal 2020 with a total of 174,097 customers based on an active subscription or maintenance agreements. The company said it added 3,046 net new customers during the quarter. However, it recorded a net loss of $385.2 million for the fourth quarter of fiscal 2020, which included a non-cash charge of $382.7 million.

    Atlassian tools can be deployed on-premises or in the cloud and the company has been offering discounts to IT organizations as an incentive to entice customers to shift to the cloud. In the wake of the economic downturn, it’s not clear to what degree organizations will prioritize spending on ITSM tools. However, with more employees and IT administrators now working from home, the need for cloud-based tools to manage a highly distributed IT environment has never been more apparent. One of the things that will differentiate Atlassian is the teams-centric approach the company takes toward ITSM and DevOps, said Wong.

    In the meantime, as the Atlassian ITSM and DevOps portfolio expand, IT teams should expect the divide these two distinct approaches to managing IT to continue to narrow.

  • Measuring Success in DevOps: Top Four DevOps KPIs

    Measuring Success in DevOps: Top Four DevOps KPIs

    There is no news in DevOps concept. Many companies have integrated DevOps to improve and accelerate software development and help drive their digital transformation, and that number continues to grow exponentially. There are now entire tool ecosystems, methodologies and transformation models—as well as endless resources—available to guide companies along the DevOps journey.

    But DevOps success can be difficult to measure. DevOps isn’t a formal framework; it’s more of a culture and a set of practices, and there is limited guidance available to ensure you’re doing it properly or accurately measuring your successes and failures. DevOps also looks different in every organization—no two DevOps shops will be the same.

    However, despite the nebulous definition of what a DevOps organization looks like, there are some core key performance indicators (KPIs) that should be common to all DevOps environments: asset management, monitoring, continuous integration/continuous deployment and continuous security.

    Asset Management

    In this context, asset management means measuring what is automated and how effectively it is controlled. It doesn’t matter if you are using tools such as Puppet, Chef, Ansible or Terraform; what matters is how effectively you use them. These tools allow you to automatically provision bare-metal or cloud assets, as well as join a load balancer and receive traffic. However, you can achieve similar results from Kubernetes or chaining lambda functions. Automation is really about controlling assets to achieve your business goals.

    Whether you’re using on-premises virtualization or cloud workloads, taking the time to streamline your processing cycles down to the minimum hardware required can significantly reduce monthly costs. The higher the percent of your servers, containers, services, etc. are automated, the less time you’ll spend fixing and maintaining your infrastructure. Some of your applications may be uniquely configured to your particular organization, and therefore cannot be automated. However, if applications cannot be automated, it might be time to retire them and build next-generation applications.

    Monitoring

    Should you be monitoring all of your resources? Yes. Should you also filter out the noise? Absolutely. Monitoring agents should be deployed to all of your servers, and if your PaaS tools and other providers have integrations, you should be using them and parsing out unneeded data. The only thing worse than not monitoring anything is monitoring everything without proper filtering.

    Good monitoring should always be coupled with utilizing the information acquired. Capturing logs, parsing them and using tools such as ELK, Datadog or Sumo Logic, for example, give you a large kit that can not only capture and glean useful information from a tremendous amount of data, but can also make decisions and perform predictive analyses. You might learn your stack is operating inefficiently, or not scaling fast enough during peak utilization periods.

    Disparate systems should be aggregated into a common tool, lest you spend valuable time combining information across systems or pulling information from data warehouses to get your insight. Let the tools do that work for you. You should also be using tools such as Logstash to pull and understand application, database and other logs in your stack for meaningful data. If not, you’re limiting your insight into the service’s health.

    Continuous Integration/Continuous Deployment

    Continuous integration and continuous deployment (CI/CD) is the difference between releasing software once a quarter (or year) and performing dozens of releases to production within a day.

    But it’s one of the most difficult indicators to measure, since every environment is different. It is important to understand how many code commits don’t make it past your integration environment. These blockages could be the result of poor programming practices, poor code quality or poor testing. However, if features stay in dev or integration for too long, there is surely an underlying issue. In most cases, it centers around automated testing.

    So, how do you measure good testing? This is one of the most difficult questions enterprises face, especially when automated testing is added after monolithic applications are already written. Essentially, good testing is about creating good business logic and integrating testing that meets most use cases, while covering each function and class. Immediate feedback on failed or successful tests expedites the automation process. The less automated testing is built, the more QA has to test by hand. Failing to integrate good business and integration testing slows down the entire CD part of the pipeline significantly. Also remember shooting for 100% test coverage is unrealistic—over 80% should be sufficient.

    It’s also important to remember applications that are not in a pipeline and must be manually tested will never keep up with the pace of cloud-born innovation. If you are dealing with a giant, monolithic legacy app, it’s time to design its replacement (starting with testing). Pipelines should also have notifications built into them, with chaining logic to react to failures. Tools such as Jenkins, CircleCI, TravisCI and most code repository solutions, such as GitLab, offer rich feature sets to aid in pipeline creation and management.

    Continuous Security

    The easiest way to ensure security compliance is to shift left and resolve security issues in the development stage. Too often, security is applied at production, which means it’s not part of the environment’s end-to-end process. Securing applications and networks at the development level will give you more confidence that applications will interoperate properly at the production level.

    After shifting left, make sure you continuously deploy and monitor your clusters, nodes and pods in a secure manner. Ideally, you have a tool that provides a real-time summary of your cluster’s compliance and security status by looking at workload security and governance checks, cluster worker node CIS Kubernetes Benchmark checks, cluster Ingress controller security best practices and istio security checks.

    DevOps Success Never Ends

    Success in measuring your core DevOps KPIs is not about getting to full automation immediately—it’s about understanding your biggest issues, continuously securing them and improving them over time. DevOps has no end; success requires continuously measuring your progress and improving your environment with the most effective and up-to-date tools. Take control, implement thorough and meaningful monitoring, deliver with confidence and do it securely.

    — Gadi Naor