Tag: policies

  • Google Launches Software Supply Chain Initiative

    Google Launches Software Supply Chain Initiative

    Maintaining the integrity of a software supply chain is an issue that has long bedeviled IT organizations. With the rise of microservices based on containers, however, this issue has become more acute. As a result, software supply chains are an issue that Google now plans to tackle.

    Google, along with JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security and CoreOS, is taking the lead on an open-source Grafeas initiative that aims to create a standard application programming interface (API) through which metadata about the software components that make up an IT environment can be more easily captured. The whole software supply chain issue has become even more challenging now that enterprise IT organizations regularly make use of open-source software within larger applications. There are now more dependencies on software modules that are being created and updated outside the IT organization, most of which are not prepared to keep track of the modules’ history.

    One of the first instances of Grafeas is going to manifest itself in the form of Kritis, a policy engine that Google has developed for the Kubernetes container orchestration engine. Because of its long history with Kubernetes, Stephen Elliott, product manager for developer platforms at Google, says Google tends to approach every issue these days through a container prism. But the expectation is that the Grafeas API will be more broadly applied to collect data about and enforce policies across a broad range of types of software components, he says.

    Elliott says that while there is no shortage of tools for managing software life cycle, each of those tools generate their own proprietary metadata. Grafeas promises to provide a consistent means to, for example, identity developers, determine when the code was checked in and built, what vulnerabilities have been detected, and what tests were passed or failed. Trying to manage those issues is at the heart of any approach to DevOps. A standard API would not only go a long way toward simplifying those issues, it also should also serve to make many of the tools DevOps teams rely on today more interoperable. That would also go a long way toward preventing IT organizations from finding themselves locked into a specific set of DevOps tools.

    Obviously, the launching of an initiative represents only the beginning of a process that should extend well into 2018. The number of IT vendors that have a vested interest in software supply chain issues exceeds that number that has signed on to the Grafeas initiative, and when this API issue is addressed by an industry standards body remains to be seen. Google is betting that as IT organizations become more familiar with microservices-based containers, there will be lot more support for addressing these issues now than anytime in the past. In the meantime, IT leaders should take some comfort in the fact that, at the very least, the IT vendor community is starting to better appreciate their software supply chain pain.

    — Mike Vizard

  • Seeking the Balance Between Federalism and States’ Rights

    Seeking the Balance Between Federalism and States’ Rights

    When you overhear someone talking about federalism versus states’ rights, you are bound to think they’re talking about national politics. In the meeting rooms of corporate America, however, it’s often a very different discussion going on.

    For product engineering teams in a medium to large corporate context, many topics and discussions boil down to federalism versus states’ rights wherein federalism relates to the interests of the corporate parent and the states in question are the business units or individual product teams. The representatives from each of these bodies often have distinct agendas and priorities which sometimes compete with each other and all too often leave employees and executives alike flummoxed and resigned to pain.

    The Federalist Perspective

    The people who are charged with driving unification and standardization may indeed use their process and policies as sword and shield, but this doesn’t mean they don’t have a well-reasoned position that drives them. Almost every employee is familiar with the drive to create revenue. Not nearly as many are familiar with the charge of “driving the spread.”

    A business could be viewed as healthy when revenue grows at a rate that exceeds the cost of capital (i.e., “investment in the business beats investment in the market”). Better yet, a business can be viewed as sustainably healthy when revenue grows at a rate that exceeds the cost of capital AND operational expense grows at a smaller rate. This is what is known as increasing “the spread.”

    When the spread grows year over year, it means the business is succeeding at increasing both effectiveness and efficiency at the same time (i.e., “doing the right things right”). In most cases that don’t have explosive market growth, driving the separation between revenue growth trend lines and operational expense growth trend lines is one of, if not the best, metrics for the sustainable health of an enterprise, because the increasing spread acts as a lever to fend off disruption and competition by raising barriers to entry or funding acquisition of potential disruptors.

    If your job within the company is to increase the spread for the entire enterprise, the best tools at your disposal are to drive standardization and consolidation in all things by default. In this context, “all things” really does mean “all things.” It includes—but is not limited to—tech stacks, support levels and processes, operating procedures, job descriptions, programming languages and frameworks, employee policies, employee tools, business process systems and core capabilities.

    This drive for rationalization often will come into conflict at the business unit because individuals at all levels within the business unit will many times be asked to drive change that could sacrifice the performance metrics and commitments that are measured at the business unit level.

    In the eyes of the federalist, sacrificing pennies for the sake of dollars is almost—if not—always the right thing to do for the enterprise.

    The States’ Rights Perspective

    The people who are charged with driving business unit performance may indeed voice their displeasure at corporate direction with an attitude that displays a lack of professionalism and respect, but this doesn’t mean they aren’t fighting for a just cause. Supporting the whole at the expense of piece is something that most people can understand. Not everybody, however, can see the cost that comes when unification erodes peoples’ sense of self-determination.

    Individuals and individual business units alike are extrinsically driven and rewarded by achievement of individualistic goals and commitments. Many of these same individuals are intrinsically driven by a sense of autonomy, mastery and purpose. Autonomy at its basic level is well-understood.

    When new directives for unification or standardization are rolled out, this introduces both direct and indirect cost at the business unit level. These costs aren’t always funded to the extent necessary to drive the required rationalization. Even in the case of reasonable funding, relief from existing commitments isn’t usually factored into corporate directives.

    Funding and wholistic concerns aside, what can be the hardest dynamic to work through is directed idleness while fully aligned decisions are being generated. From the practitioner perspective, this dynamic can be perceived as contemptuous because it simultaneously says, “Your concerns are not sufficient to warrant our attention,” and “Don’t take any action to address your concerns because that will warrant our attention.” In the most extreme cases, this is coupled with an unyielding expectation to meet or exceed performance goals.

    This approach breeds a combination of labor attrition, forced helplessness and a jaded attitude within teams that can take years to unwind and change.

    The Balanced Perspective

    Splitting the middle can be difficult in emotionally laden high-stakes areas. Add distrust and a high degree of power separation, and the degree of difficulty gets intense for this effort. Let’s start from the top because the onus is on leaders to go first when an impasse arises:

    Where federalists can give in efforts to support self determination:

    • Even the most ardent federalists agree that autonomy is the only path to achieve scale in a modern corporation. Central bodies of authority can go out of their way to demonstrate their commitment to this by endorsing explicit role-specific areas where experimentation and innovation is needed (i.e., a message of, “Don’t advance here just yet,” goes down easier if it’s coupled with a list of topic areas that have few or no guard rails).
    • Assuming current commitments are not in jeopardy, acknowledge that work done in excess of current commitments is a contribution and not a distraction, even if it has the localized possibility of deviating from to-be-set standards (i.e., a message of, “Don’t spend time on improving area x,” goes down a lot easier if it’s coupled with an acknowledgment that, “If a person is willing to dedicate their own personal time, that does not come at the expense of the company. We value that level of commitment”).
    • Find ways to recognize and reward individuals and teams for avoiding local optimization at the expense of the whole to compensate for locally defined goals and compensation systems.

    Where states’ rights activists can give in an effort to support a broader set of goals:

    • Even the most ardent localists acknowledge the pricicipal within a hierarchy of goals (enterprise goals > unit goals > team goals > personal goals). Local leaders and practitioners can go out of their way to demonstrate their faith in leadership by going the extra mile to find and generate goal alignment that drives benefits to more than one organizational unit (i.e., a stance of, “We’ve prioritized local remediation in this one area because it helps our business unit meet some secondary objectives,” invites less opposition if it’s demonstrably linked to the broader set of enterprise goals.
    • Assuming room for innovation and continuous improvement is met with tolerance, local leaders and practitioners can make themselves beyond reproach by ensuring goal priorities have been kept in mind and also focusing improvements that have limited to no impact outside of their local responsibility (i.e., a local development push to a microservice architecture can have deep impacts to a centralized operations unit without a diligent effort to manufacture a mature operational capability).
    • Find ways to drive local improvement communications up to broader system owners in an effort to facilitate collaboration and longer-term planning (i.e., a message of, “Business unit x has developed a new solution for y,” raises a lot less concern when it’s paired with a statement of, “… and the teams acted responsibly by collaborating with the enterprise team responsible for keeping our long-term efforts here aligned with a consensus road map.”

    When deference and forbearance meet, graceful and elegant solutions emerge and ultimately harmony is preserved. If only more people understood that the adversarial noise in between us is more harmful than either minor deviance, or momentary ambiguity.

    — Stephen Fishman

  • Trusting Continuous Delivery

    Trusting Continuous Delivery

    DevOps, continuous delivery and the pipeline for faster software development are fundamentally different from traditional software development. It’s such a different approach and a different culture that it can take some time before Dev and Ops teams embrace and trust it—a necessary step for DevOps to make progress in any organization. By mixing containers and their value proposition into DevOps, this new software creation and deployment paradigm can readily foster that trust.

    What Continuous Delivery Brings

    DevOps and continuous delivery offer application development using containers, providing the required level of trust to get over that hump and move things forward. According to David N. Blank-Edelman, a DevOps veteran and currently technical evangelist at Apcera, the following container features lead to trust because they answer Dev and Ops concerns:

    • Containers are resource-friendly replacements for virtual machines, built to encase the coder’s development environment
    • Containers are the complete package format replacement, possessing everything you need to run an app
    • Containers create an abstraction that enables development and its results to sit in a host in any of a number of infrastructures including on-premise and inside any of several public cloud providers
    • Containers are the fastest means to launch short-lived, purpose-built testing sandboxes as part of a continuous integration process
    • Containers are the end result of a build pipeline (artifact-to-workload)
    • Containers form the boundary for loosely coupled components as part of a larger app or service. Such is the case, for example, when each part of a microservice-based app lives in its own container

    According to Blank-Edelman, the aforementioned features imbue trust because they satisfy the following Dev and Ops queries:

    • Is the container allocated to use only the resources it should?
    • What resides in that container / workload?
    • Where did that container come from? Is it OK from a security, coding and business requirements perspective?
    • Where is the container permitted to live and run such as in what cloud, environment, country, and in proximity to other containers technically?
    • Can the container communicate with only the things it should such as other containers and any hypervisor or other management resource? “If I move the container to another location, do the answers to these same questions still apply?” asks Blank-Edelman.

    Though these questions express concerns in direct and simple language, experienced DevOps engineers who have felt the frustration of building development processes and attendant infrastructure understands these are difficult questions to satisfy. Without modern containerization efforts to sustain DevOps, development and production goals grow further out of reach.

    The Importance of Policies

    As containers undergird DevOps and continuous delivery, policies support containers. Developers input changes and innovations in code to the continuous delivery pipeline. Developers then respond to the needs of the growing code in a nurturing fashion, fixing errors and enabling new features. This pipeline works when automation, together with each progressive step in the development process, lays a foundation for the next step in a predictable and reliable manner.

    “Here’s where it gets tricky: First, not only do you have to be able to answer the trust-related questions for each step, but it is entirely possible (and entirely likely in an enterprise environment) that different people/teams will share control of and input to each step on that path,” says Blank-Edelman. With so much collaborative effort in play juggling all these pieces, policies are necessary to configure these steps, address networking and other elements, and control the component parts of the process ahead of time and everywhere along the way.

    Policies that make particularly good container watchdogs include those that set steps in the DevOps/continuous delivery pipeline apart, hemming them in on all sides. “Just like having your papers in order makes for an easier border crossing when you travel abroad, so, too, does having your policies reflect the trust required to move from one step to another,” says Blank-Edelman.

  • Security Policies For DevOps 101

    Security Policies For DevOps 101

    A while back I was talking with some friends about how to ensure security inside a devops environment.  The simple first thought was that no where does DevOps say to do away with security.  Instead, consider how your existing information security practices and policies need to adjust given the changes that DevOps brings to the working environment.  Veteran security professionals understand that many security practices begin with policies.  Furthermore, no policy is ever set in stone. Failing to update policies and procedures at least every year is already a recipe for disaster.

    I tell a lot of people to think back when the iPhone was first introduced.  The natural tendency of security professionals inside IT organizations was to either 1) simply ignore the device or 2) establish a flat out denial kind of policy.  Neither choice was even near the right answer.  I can say first hand that I was victim to this kind of tunnel decision making.  We updated our mobile device policies with a flat out “no iPhone for you…come back in 2 years” doctrine.  My feeble attempts to fend off iOS devices lasted maybe a year.  Meanwhile, lots of people at the office were seen with iPhones in hand who continuously said things like “but I’m not using it for work”.  Flat out denial on both mine and their parts.

    Bottom line, policies are meant to be changed for the changing environments.  DevOps is no different.

    The Minimum Requirements

    Just like in development how we talk about the minimum viable product, we can apply the same concepts to implementing security practices.  For starters, make sure your organization has a few policies drawn up, agreed upon and stamped with the approval of your executive staff.  The minimum set of policies any organization needs should include: network or Internet security, computer security, information and intellectual property security policies; secure software development policies and procedures.

     Be the Champion

    But the job doesn’t stop at policy creation.  Even having your executives agree to the policies doesn’t mean they will be followed or even understood by your DevOps teams.

    I speak to security heads often and tell them they need to get out of their seats and speak to all the employees in a company.  One of the first conversations to have is to begin championing the security policies.  Make sure people understand the policies and more importantly understand the reasons for the policies which have been selected.

    Do you remember going to high school and being told you have to follow a rule that you thought was totally asinine?  Non security folks will probably think the same about silly policies and might even act out purposely against them. A champion needs to teach and live those policies.  And when someone challenges the policies, then take the time to have a two-way conversation with them.  Make sure you understand their point of view first before you try and push your silly security ideals on them.

    Taylor Your Policies

    While the policy template available online, like those available from SANS, are a great starting place, don’t just slap those on the intranet as-is.  Read them and make adjustments for your company, for your culture and your development practices.  Even better, include policies that are specific to cloud and DevOps.

    One area of customization to start with is to create policies for specific cloud vendors.  For example, consider setting policies around how to the company should be using the Amazon’s IAM feature.  Make specific policies around how IAM users and groups should be configured and used.  Use the doctrine of least privilege and design a sane access control policy.  Consider a policy where only a few trusted users have full admin access and other users are in a power users group where they can launch instances, but cannot alter AWS console configuration or access.  You might want to give your accounting team limited access to the console as well to review billing and usage.  While you are at it, develop specific policies around the use, distribution and storage of cloud API keys.  Furthermore, consider enforcing two factor authentication.  These kinds of specific use case policies will go a long way for security teams in gaining confidence with the DevOps teams.

    DevOps might be the cool new hotness that is making waves in every kind of organization, but that doesn’t mean we can forget our information security requirements in a DevOps environment.  One of the starting points in ensuring DevOps organizations follow good security practices is to start with a minimum set of security policies.  Make sure you champion these policies and tailor them to your specific organization and use case.  With a little luck and determination even your DevOps teams can follow security best practices.