Tag: automating security

  • The Scanner We Really Need

    The Scanner We Really Need

    IT has scanners for everything. And by everything, I mean everything. We scan source code for vulnerabilities and data leaks. We scan apps for vulnerabilities. We scan the network for holes. We scan our cards for access … Okay, that last one doesn’t fit, but you get the idea.

    Know what we don’t scan for (and what I propose we start scanning for immediately)? Secrets. Oh, there are apps that include finding secrets as part of their feature set—but only a part—and they only scan for secrets within their domain. What we really need is something all-encompassing. Secrets have a way of turning up everywhere—Git, flat files, databases, source code, email … If it can store text, your secrets are probably in there. The larger the organization, the more true this is.

    Way back in the day, I started working at a company that had mainframe admin credentials stored in a flat file on the network. I am not an InfoSec employee, but I can smell insecurity easily enough and I told them to knock it off.

    I am not mentioning the company by name because this is not indicative of their practices today, nor am I mentioning my position or the market, because anyone interested could then use my LinkedIn profile to figure out who it was.

    In my role there, I had the authority to tell them to knock it off, but they handed me a ready response: “Our network is secure, so we don’t have to worry about it. And we monitor the file … some …”

    The same type of mentality seems to permeate IT today. Security by obscurity is alive and well with regard to secrets, and yet we as an industry know (from hard-earned experience) that it is largely a myth.

    So, we need a tool that can access all the places that secrets might be hiding and ferret them out—I’m thinking like a simple UI that takes a secret and searches for it in all of the configured places—would be perfect. Well, almost perfect. Iteration 2.0 would report on what is accessing the secret in that location.

    Get secrets management. Several markets offer secrets management as part of a toolset, you might even own a product that can do it for you. Then, given the search tool and a good secrets management solution, you could search out all instances and replace access to them. Until iteration 2.0 comes out, you could replace them in a test environment and see what breaks—though we also have the hard-earned experience to know that this isn’t foolproof, so you’ll want to heavily document the change for that odd thing that breaks 20 months from now.

    This is not that difficult a product to design and build; finding where each secret is accessed from would be the hardest part. But that’s still doable with our current dev tools. One of you should build it and get rich.

    But meanwhile, as always, keep rocking it. Secrets stored in not-so-secret locations or not, you’re keeping the company running day in and day out. That makes you the stars of business. Keep up the good work.

  • ARMO Aims to Simplify Microservices Security

    ARMO Aims to Simplify Microservices Security

    ARMO this week emerged from stealth to launch a platform to secure cloud-native workloads and improve visibility. The ARMO Workload Fabric technology attaches code within the memory invoked by a microservice to enable cybersecurity policies to be applied via a cloud service.

    Company CEO Shauli Rozen said the ARMO Workload Fabric is designed to enable IT organizations to implement a zero-trust architecture more easily within the context of a DevSecOps workflow.

    Fresh from raising $4.5 million in seed funding, Rozen said ARMO’s approach eliminates the need to deploy and manage agent software, container sidecars or runtime application self-protection (RASP) software to enforce security policies across what inevitably will become thousands of microservices distributed across an enterprise IT environment.

    That leaner approach then allows for a centralized management platform that can be deployed on a cloud or on-premises IT environment to apply policies that restrict which microservices can communicate with one another, Rozen said. The approach would ensure that only microservices developed using a continuous integration/continuous delivery (CI/CD) platform are allowed to communicate with other microservices, Rozen said.

    Integration with multiple CI/CD platforms is already provided, added Rozen.

    That approach allows policies to be applied to microservices regardless of how they are constructed, Rozen said. That capability is critical, because developers are building microservices using everything from Python and Java to containers, he said. Many of those microservices are also frequently replaced, Rozen said, which can make updating any associated agent software a significant DevOps challenge. Given all the existing dependencies between microservices, overall application environment security is only as strong as the proverbial weakest link. The ARMO Workload Fabric enables developers to add a small amount of code to implement security policies each time a microservice is rolled out into a production environment.

    As part of an effort to make it simpler for IT organizations to apply those policies, ARMO provides a pre-built set of policies that organizations can immediately apply, in addition to creating their own polices over time, Rozen said. In many cases, IT teams simply don’t have the time or expertise required to build those policies, Rozen added.

    Microservices are being built and deployed at such a breakneck pace that it’s nearly impossible for cybersecurity teams to keep up. The ARMO Workload Fabric provides cybersecurity teams a means to centrally manage security policies that would otherwise be implemented as code by developers. It provides a level of observability for how those cybersecurity policies are being implemented across microservices that typically have a lot of dependencies on one another, Rozen said.

    Most organizations today recognize there is a clear need to shift responsibility for application security further left toward developers. The challenge is finding a practical way to achieve that goal, and in a way that doesn’t adversely impact the rate at which applications are being developed. The key to achieving that goal is finding a way to apply microservice security polices that causes the least amount of friction possible to existing DevOps workflows.

  • Building a Security Feedback Process for DevOps

    Building a Security Feedback Process for DevOps

    The last few years have seen some major slip-ups in the security space among all major cloud providers, resulting in uncertainty and speculation. That’s understanding; cloud security is an extremely complicated subject as enterprises build and deploy applications faster than ever before to keep up with business requirements. Most of the security issues that occur in the cloud today are around compromised accounts, identity theft, malware apps and, of course, data breaches, which are business-critical and showstoppers, in many cases.

    Given the dynamic environment of DevOps and the nature of the cloud, it’s a complex problem to address and fix. The most effective way is to embed security, or what is usually talked about as the shift-left of security, in the IT pipeline. If DevOps is the culture of collaboration to reduce risk by the size of change, DevSecOps is the automated security control built into each point to build a sort of self-defense mechanism.

    DevOps is not about tools; it’s about philosophy and process. One of the most important processes to include to succeed at DevOps is a feedback loop that reinforces constant collaboration.

    This is certainly true when it comes to security-related information. In a healthy DevOps organization, security problems that are detected at any point in the delivery pipeline are communicated quickly to all stakeholders, who can, in turn, respond accordingly.

    In this post, we will look at the steps involved in building a security process that will ensure the right information reaches the right people quickly and that teams collaborate without duplicating efforts.

    Automate Your Way to Better Feedback

    Automation is the first step, and a no-brainer when it comes to DevOps. Without automated security tools for code analysis, configuration management, access control, vulnerability management and secrets management, it is very difficult to scale security in a dynamic DevOps environment. Manual efforts in the cloud are doomed to fail in many cases, as environments change rapidly. Hence, automate. The recommendation is to automate every security control and the entire feedback process as much as possible.

    Manage Roles Right and Control Their Accesses

    Identity and access management has become the linchpin in cloud security. Since it’s very easy to give people the wrong access, it becomes important to figure out who can access what resources. Access to information and resources must be secure, yet easy to obtain. All access should be given to a group rather than an individual. Mapping security access to the organization’s hierarchy is an effective way of establishing a communication loop. The right information reaches the right group of people. It is important to be able to answer questions such as the following to ensure the communication loop is efficient:

    • Who can delete this VM?
    • What are the resources a certain user has access to?
    • Who has service accounts access?

    Tools that show a relationship between users, groups, roles, permissions and resources help answer these questions.

    Encrypt Secrets, Manage Their Keys

    Another important step to building an effective communication cycle is controlling access to application-level secrets. Security can be improved by tightening information flow between relevant groups, which can be accomplished through creating and controlling access to secrets using principles of least privilege. Access keys to those secrets can be kept in a centralized secrets management tool or a key management tool. The rotation of these keys can be automated as often as required.

    Designing for Failure and Proactively Managing Vulnerabilities

    Though security personnel may cringe at the mention of the word “failure,” designing for failure means thinking ahead and having a plan B. The cloud is dynamic by design and things happen at an incredible pace, often resulting in issues of elasticity, configuration and cloud power.

    Context becomes an important parameter for managing vulnerabilities because there are multiple vulnerabilities at any given time. Automated vulnerability management and configuration management solutions are available to take the complexity out of protecting cloud environments. Automation capabilities and continuous monitoring provide deep insight, intelligent recommendations and continuous protection of the cloud, thus ensuring effective management of information in the feedback cycle.

    Log Everything — Everything

    Just embedding security to shift left is not enough to ensure security. It is important for all relevant collaborating groups to know the status when some code is deployed. The primary source of visibility and feedback comes from logs. Effective logging strategy is the paramount attribute of security design. Logging should be enabled everywhere possible: data access logs, identity logs, admin activity logs, logs within the cloud environment, OS, network platforms, etc. Logs, though cumbersome and volume-heavy, are non-intrusive and a critical visibility tool. You need to know what’s going on before deciding to do something with the event itself, which brings us to the next step: monitoring.

    Monitor Those Events

    Testing departments often seem paralyzed with too many flags, which prevent them from prioritizing critical issues. Having log and event data is an important first step, but the absolutely necessary next step is to relay them into an automation strategy that will separate the unimportant, voluminous issues from business-critical priorities. Automated monitoring for events triggered makes the feedback cycle more effective. Otherwise, logs can become noise—a copious amount of noise.

    Alerts and Notifications

    We embed security in the code. We manage access and roles. We turn on the logs and monitor them. An event occurs. Now, who do we alert? An effective alert notification policy will ensure that notifications are sent to the right group of individuals, depending on the notification filters—the level of criticality and relevance of the issue type. Notification policies specify the conditions that trigger a notification that will be sent to the recipient. Notifications can be sent by email, SMS, voice, push messages, etc. A recipient can then acknowledge the alert, which indicates to other users that someone is working on the issue, thus avoiding duplication of efforts.

    Conclusion

    To conclude, automating security controls and feedback cycles enables a productive DevOps ecosystem by exposing vulnerabilities early in the product life cycle. Automation, streamlined communication and appropriate response to priorities ensure availability, network connectivity and resilience. At the same time, they reduce the possibility of a data breach and duplication of efforts. At the heart of everything is the ability to deliver code in a secure and reliable way to meet ever-evolving business needs with agility.

    To see how Symantec can help maximize security in a DevOps environment, check out a free trial of Symantec Cloud Workload Assurance.

    This sponsored article was written on behalf of Symantec.

    — Twain Taylor