Last week I introduced key agile concepts including the history of and essential roles required for Scrum practices. I described a real-world example of how DevOps could have saved my organization major headaches and expenses.
In Part Two of this post on using agile Scrum methodology within DevOps ecosystems, we'll examine the Four Values of Agile and learn how to change your organizational mindset to accommodate this new paradigm.
In early 2001 I was involved in a software development project on integrating bolt-on application to a JD Edwards ERP software platform. The team completed the initial requirements collection and developed a comprehensive Business Requirement Document (BRD), investing roughly two to three months. The team had multiple review sessions to identify gaps in the requirements process and after a few cycles received approvals to proceed to the development phase.
While development was in progress, some of the EDI-based vendor data sources changed the mapping. This situation created chaos in the project. The management team decided to hold off the development phase. The project had to go through the requirements cycle again to identify the gaps. This situation impacted the schedule and budget, creating massive frustration in the organization. The first six months of the project investment was on hold. The sequential software development process we followed did not allow the flexibility to deliver any incremental value to the organization since the beginning of the project.
If we had followed an agile approach, this challenging outcome might have resolved in a different manner. The short intervals of development would have produced incremental value to the organization. Therefore we would have minimized the organizational concerns of not providing any value for six long months.
Here's how agile practices, Scrum, and DevOps all work together. Learn how to overcome adoption obstacles and several keys to Scrum success in this two-part blog series.
We have received requests to see more detail around what is happening while Beekeeper applies patches for devices. We have built a PowerShell script to query Beekeeper and the patched devices to display what is going on within Beekeeper and show the progress on individual patches.
To execute the script, you can run it on the Beekeeper server. Learn how below.
Ransomware is a digital attack in which an executable or malicious link opened by an unsuspecting (and likely untrained) user installs a program that blocks access to applications, phone systems, and/or data until a ransom is paid. It’s been making the rounds for many years now. But only lately have hackers begun zeroing in on a specific vertical: state and local governments.
In 2019, over 22 governments have been affected by ransomware – and that number was prior to recent news breaking that an additional 22 small towns in Texas were all targeted in a single coordinated attack.
Over 200 state, county, or city government IT systems have been targeted in recent years. With thousands and thousands of cities and towns across America, that may seem like a drop in the bucket. But ransomware is becoming easier and easier to distribute and users continue fall victim; usually via phishing emails or web exploits that deliver malware without any user action outside of visiting an apparently innocuous site.
Why are governments becoming a preferred target for ransomware? And how can you improve your chances of avoiding or mitigating ransomware?
In InfoSec we continually encounter the unknown, the unfamiliar. Technology marches ever forward, application design matures, bells and whistles chime and toot. This commonly results in the InfoSec professional needing to responsibly secure technology that they don’t holistically understand. Attackers know this, for it is within those gaps in understanding that malicious activity may most readily occur and may do so without notice.
A common InfoSec response to the unfamiliar is to attempt to cover all potential angles of attack, regardless of whether they are pertinent to the technology. This is done in order to ensure that we meet both risk and governance management goals. The result of this approach is rarely better security. Rather, it typically results in unnecessarily complicated security control implementations that are neither functional (e.g., they don’t do what we want/expect them to do) nor operational (e.g., our personnel can’t adequately manage them).
How do we avoid over-complication in our security controls? We focus on the fundamentals: Preparation, Awareness, Response.