devopsy.kinsta.cloud

Tag: devops challenges

  • Secure Your Network: How to Integrate EDR and DevOps

    Secure Your Network: How to Integrate EDR and DevOps

    DevOps and Endpoint Detection and Response (EDR) solutions converge when no human element is required while deploying applications or detecting the threat and executing preventive measures. In this article, I am evaluating how the DevOps process integrates EDR solutions for securing services operations at various endpoints in the network.

    What is DevOps?

    DevOps has an impact on the mindset and technology landscape of software development companies to build cloud compatible services in a highly competitive market environment. Unification of development and operations is streamlined in DevOps that results in more innovation in technology domain driven by software. With DevOps, automation has become a more critical element than software development cycles. Now, updates, fixes and patches to software application services become easy with DevOps.

    DevOps Challenges

    Over time, it is realized that security is overlooked while moving to DevOps culture. Here are some of the challenges the DevOps approach might have:

    Absence of Security Knowledge: It is a known fact that a lack of knowledge of secure coding and ignorance of robust security practices by developers can cause a long development cycle. It can happen due to training to developers for following security methods and guidelines while writing code and committing for the build. It has to be addressed at the development level by companies.

    Open-Source Software Security: Use of open source frameworks has increased over time in a DevOps approach. With open-source projects, DevOps teams get pre-made code snippets to enhance the functionality of applications. But a striking fact is that 41% of cyber-security applications found high-risk open source vulnerabilities. To encounter this challenge, the DevOps team should be literate to track updates to open source frameworks used in DevOps toolchain, apply fixes to vulnerabilities as it becomes available. Also, to integrate open source, only use the trusted repositories.

    Inverse Speed for Security Testing: DevOps introduces automation with agility in developing and releasing software applications. The speed at which developers commit code and build an executable does not allow the testing team to deep dive into code efficiently. In the traditional model, testers used to get a fair amount of time before applications go live. With the new agile approach, the duration for testing becomes much lower. To tackle this, automation in testing needs to be in line with development.

    What is EDR?

    EDR solutions offer a new approach to continuously monitor network endpoint devices for malicious activity and prevention of the attack and trigger a further course of action based on the pattern of attack. These solutions analyze endpoint data actively to provide detection and prevention in real-time. EDR solutions analyze the behavior of endpoints users and/or devices for suspicious activity and send alerts to the system.

    EDR replaces the use of digital signatures to detect threats and provide behavior-based solutions for proactive security threat intelligence. All the processes of EDR solutions are based on activities, events and interactions on endpoints or with endpoints. 

    In the realm of CyberSecurity, EDR security offered to enterprises has the topmost priority due to its nature of being proactive and automated. 

    How Does EDR Solve DevOps Challenges?

    DevSecOps is all about introducing and utilizing tools/solutions to secure continuous integration, development and delivery of applications. These applications made for services run at either server-side or endpoint devices. EDR solutions work actively in systems where endpoints have participated. EDR solutions can be integrated within the DevOps cycle so malicious activity can be tracked and hunted down by developers. This can be the quickest and automated way to tackle security threats.

    The public cloud provides an environment for developers for the development, testing and execution of applications. The DevOps approach is mostly consumed by public cloud vendors with their set of supporting tools. But the cloud has its security concerns—such as any misconfiguration or code glitch in the application resulting in a huge attack. Also, cloud resources are mostly accessed by various types of devices which may or may not be secure. Some developers use their own devices for the development and monitoring of the application. EDR solutions can help in both cases by applying itself at endpoints as well as at public cloud infrastructure end.

    Conclusion

    EDR solutions are based on machine learning technologies that generate actions based on analytics information provided by sources/endpoints. EDR tools integration with the DevOps toolchain takes automation in process execution at much further level to track security breaches in run time and hunt down vulnerabilities within code before the application goes live. Additionally, it has seen that endpoint devices are more significantly emerged in generating security incidences. It has become imperative for DevOps teams to look after endpoint protection.

    — Sagar Nangare

  • Top DevOps Challenges at DOES19

    Top DevOps Challenges at DOES19

    I recently attended the prestigious DevOps Enterprise Summit in London. During the three-day event, I asked people what their major DevOps transformation challenge is. I wanted to examine these at global events, asking the same question.

    I was GamingWorks’ booth boy at the event, which gave me a chance to ask a lot of delegates visiting the stand.

    Here is a summary of what they said, with my commentary based on what I have picked up on my travels as The IT Paradigmologist.

    Business Value

    • Understanding the link between IT work and the business strategy.
    • Seeing the whole end-to-end picture (visibility, transparency).
    • Measuring the right things—team performance in terms of business outcomes.

    Commentary: Not only do IT people have difficultly understanding the business value of their work, they often are poor at articulating it to business executives. My DASA white paper, “The Business Value of DevOps,” and accompanying webinar elaborate on the topic.

    Governance

    • Finding the right balance in standardization across teams.

    Commentary: Governance is such a tricky topic. What do people mean by it in the first place? How negotiable should the boundaries be? Particularly in complex and therefore unpredictable systems, professionals need to make judgment calls and act for the best. Regarding standardization, the question is always about value: Does standardization and centralization lead to significant improvements in results without introducing frustrating bureaucracy? Otherwise, you’re better off letting the individual teams decide for themselves what is most effective for their value streams. Yes, it might be more expensive than one-size-fits-all, but the benefits usually outweigh the costs.

    Velocity

    • Doing things quickly while maintaining quality.

    Commentary: It’s a question of balance. Not only speed and quality (depending how you define it, of course), but also resilient operations, co-created value and assured conformance. I like the Deloitte #BVSSH way of putting it: Better, value, sooner, safer and happier.

    Value Streams

    • Breaking down silos.
    • Collaborating better between silos.
    • Giving more autonomy.
    • Integrating DevOps parts in a predominantly non-DevOps value stream and vice versa.

    Commentary: On the conference scene, almost everybody has an idea of what value streams are. Visit an average IT department though, and for most people it’s an alien concept. We live in a bubble. You have to take a few steps back and start from where they are. Take it step by step. Collaboration seems to be one of the top challenges as confirmed by the recent DOI skills survey, which had this as a top soft skill. It may be a soft skill but it is hard to achieve. The article “DevOps and Collaboration: Fraternizing with the Enemy” provides some guidance on collaboration.

    Ops

    • Discovering a new way of doing ops.
    • Shifting from old ops to new ops.

    Commentary: This is a very hot topic. Witness the promising changes in ITIL 4. Less process, more heuristics, more value-orientation (for instance, value streams and co-creation with the service consumer) and more human. It’s very encouraging to see how DevOps communities—some more enlightened than others—are developing their ops capabilities to restore the balance. But ops work differs fundamentally from dev work, and that has to be reflected in the way of working.

    Organizational Change

    • After the initial enthusiasm, “what’s next and how?”
    • Overcoming resistance to change and inertia in general.
    • Accepting the consequences of doing DevOps.
    • Unlearning 30 years of doing the same thing.
    • Learning quickly.
    • Developing skills to transform.
    • Assessing the risk of transformation.
    • Sharing (and learning from others’) practices.
    • Upscaling.

    Commentary: There is too much lip service and too little commitment. There are notable exceptions, but too many people are looking for the quick fix and believing they’ll find it. Good luck. As Taiichi Ohno said, “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” If you don’t know who Ohno-san is, that’s a good place to start. If you’re serious, take a look at Paul Wilkinson’s astute observations about challenges and enablers for DevOps success at DOES18 USA. You’ll notice many similarities with my findings at DOES19 UK.

    Culture and Emotions

    • Getting enough diversity in the team.
    • Getting different personalities to work together.
    • Trusting and being trusted.
    • Feeling non-DevOps teams are worth less, but not worthless.

    Commentary: More on culture and people can be had on the DOES18 blog, but it is encouraging that people are actually talking about this more often. It’s something that almost always crops up in The Phoenix Project business simulations that I facilitate for organizations. Topics such as psychological safety: whether you feel comfortable being and expressing who you are. So, do you? Dr. Christina Maslach referred to the toxicity of some workplaces with the analogy, “You want less toxic mines, not more resilient canaries.” Work-in-progress.

    Tooling

    • Understanding which tools are around (tool confusion).
    • Integrating and then orchestrating tools.

    Commentary: Finally a topic I know little about, but I wholeheartedly endorse many vendors’ socks.

    — Mark Smalley

  • Top 5 DevOps and Operations Challenges in 2015

    Top 5 DevOps and Operations Challenges in 2015

    DevOps and operations teams are under increasing pressure from tech-savvy, app-centric business users to collaboratively solve complex business problems with IT. Adding to the battle, the pursuit for the perfect synchrony between software development and IT operations is still ongoing, and striking the balance won’t happen any time soon. New tools, technologies and processes change and grow at a problematic pace – leaving us with no option, but to accept and address all upcoming challenges.

    Teams must keep up the pace to succeed, but operations teams cannot handle it solo and must work closely with DevOps.  The operations group is responsible to drive flawless, organization-wide execution – this was a straightforward request when the systems were configured and maintained by operations. However, recently, development became more collaborative, with involved users demanding more, using the newest tools and making the process harder to manage. Additionally, the product environment of business users has rapidly moved to portable devices, which are self-contained and hungry for enterprise-wide cloud services. This shift has created five principle challenges. These are my top 5 DevOps and Operations challenges for 2015:

    Challenge 1: Building the DevOps Culture

    Culture is an abstract group of ideas and behaviors, which makes it hard to identify a standard collection of requirements. It is much easier to decide which tools to use and how to use them in the most efficient way. Tools are material objects, but the people who use these tools are much more complex and difficult to change. As DevOps is all about continuous change – including reconfiguring a company’s core culture – there is a steep hill to climb.

    Replacing traditional development and operations silos with cooperative teams of people from both camps can only get us so far. While DevOps is supposed to intentionally foster collaboration and results-driven effort, it needs the support of operations. Until operations can identify how to embrace the new mentality of culture-fostering activities into its daily regimen, there is no way to help this aspect of DevOps grow.

    Challenge 2: Meeting the Quick-Fix Tool/App Mentality

    While most end users now rely on a wide palette of tools to get their job done, they often circumvent the IT department to get the tools they prefer. As many are open source or offer initial trial versions, unsanctioned tools can be adopted without any internal oversight – leading to major issues down the road.

    Making matters worse, business users believe everything can be solved with an app, but that is often untrue. While it is the overwhelming consensus that every tool should have an easy-to-use app, making the app a useful, secure one is much more complex. Even if there is an “app for that,” it must be properly integrated to back-end systems as part of the cohesive enterprise infrastructure. DevOps must balance tool delegation and management early on.

    Challenge 3: From Legacy to Cloud

    Technology-savvy business users may want to use the latest tools, but that is a tall order for operations. When it comes to DevOps tooling and configuration management, there is still a lot of confusion as to which tools do what, and how they play with each other – if it all. Tools need to be compatible with existing solutions and technologies used by the company, and that is becoming increasingly complex with the rise of hybrid environments.

    New hybrid environments include on-premise tools, IaaS tools like Amazon, Google or Azure, PaaS compute services, and SaaS business applications. Somehow, DevOps must ensure that they all work well together and deliver a seamless experience for the business user.

    Challenge 4: Networking

    Network engineers – if they are applying automation at all – are either doing ad-hoc scripting or tap a dedicated software engineering team to build homegrown systems for their use. Inflexible networks run rampant in today’s IT environments.

    Looking for an example? Even vLANs have a spider web of interdependent IPs, ports, routers, routing tables and perimeter networks. Changing, breaking, moving or replicating any part of that intricate web often seems impossible.

    Challenge 5: Marginalized and Changing Budget

    Taking another perspective: Will customers pay more for network automation tools from the equipment vendor to make the networking user experience better? If a networking customer is spending a lot of money on the physical equipment, they often do not want additional software tools from the vendor, even if the network engineers do. The gap between the network engineering teams that need the tools and the decision makers who pay for them is widening.

    While capital expenses may be separate from operational ones, CAPEX spends are now often mirrored by OPEX ones. Trying to quantify spend on an on-premise project management tool with a SaaS application is a major headache that can no longer be left solely in the hands of the CFO. This shift impacts the structure of IT budgets – it could even take away IT’s control if OPEX spend becomes more distributed.

    What can be done to overcome these growing problems? Taking the following five steps should help you start off 2015 in the right direction.

    Collaborate Wisely:

    It might seem to get a little tense at times, but open forum discussion is well worth it. Collaboration allows teams to learn from each other and suggest possible solutions. It also encourages critical thinking and creativity. When you have different people working together on a project, you get more expansive creative input. To manage the potential leadership glut (i.e., the excess of people trying to lead the group and not that many willing to slow down and focus on a specific task), break the traditional decision-making process chain and turn it into a continuous flow of fresh thinking and ideas.

    Empower Users:

    Let your business users pick their own tools, but make sure that they report them to you. It’s a good idea to consider a library of vetted tools available for them to pick from. Encourage business users to suggest new tools so they have a sense of decision power. However, keep the tools current and make sure they actually address user needs.

    Speak Accounting:

    Try not to let OPEX issues become obstacles in tool adoption. If IT can help finance understand what is going on in the world of technology licensing vs. cloud service, it can fast track the inevitable shift, and ease budget reporting and bottlenecks.

    Break the Immutable Network Infrastructure:

    With immutable network infrastructure, you run the risk of being locked into vLAN and physical devices. What is the solution then? Leverage advanced virtualization tools (i.e. converting legacy systems to virtual machines) and take Software-Defined Networking (SDN) on board. With a centralized, programmable network that can automatically and dynamically address changing requirements, you can reduce both CAPEX and OPEX by enabling algorithm control of the network and use ASIC-based networking hardware supporting pay-as-you-go models. Deliver agility and flexibility by helping organizations rapidly deploy new applications.

    Prioritize Analytics:

    Analytics should make IT’s life easier. Build analytics and monitoring into everything from the start and think about it as “making sense” of the data or logs being collected. This information helps IT determine the true business impact of a performance issue to better prioritize where and what to troubleshoot. A strong analytics platform, where all application and tools data can be stored, gives operations the systems visibility it requires. Become a facilitator while maintaining all needed operations practices.

    There will always be challenges ahead as we work to get smarter/ faster and develop better systems and applications. However, the right analytics tools and collaborative processes designed for cloud-enabled, distributed environments can make 2015 much easier than years past.

    About the Author

    trevor-parsons-300x300-304xx300-200-0-26 copyTrevor Parsons, as chief scientist and co-founder at Logentries, Trevor Parsons is responsible for product strategy and direction. He works closely with customers and partners to continuously understand what they need, and to validate product market fit. Trevor also leads the product management and UX teams and assures the best possible user experience. Trevor enjoys speaking at local dev ops meet-ups and events, and is always looking for how log data and analytics can be applied in more and more powerful use cases. Trevor was a post doctoral researcher and member of the Performance Engineering Lab at the School of Computer Science and Informatics in University College Dublin, Ireland. He received a PhD from University College Dublin for his thesis titled “Automatic Detection of Performance Design and Deployment Antipatterns in Component Based Enterprise Systems.”  You can follow Trevor on Linkedin and Twitter at  https://www.linkedin.com/in/trevparsons and https://twitter.com/trevparsons.