[ad_1]
Learn the three areas of technical-debt accumulation that business and IT leaders need to monitor in order to reduce cybersecurity or business continuity incidents.
Image: monstArrr_, Getty Images/iStockphoto
Getting products to market before they are ready can result in lawsuits, product recalls and cybercrime. If your family car is recalled, it’s inconvenient, but cybersecurity events such as the Colonial Pipeline ransomware attack and the Fastly global outage become much more than an inconvenience. As to why, let’s explore technical debt.
Stuart Taylor, the senior director of Forcepoint X-Labs, wrote in his blog post Spend now, pay later? Settling the score of technical debt, “Essentially technical debt is the difference between the ‘price’ (time, human resources, technology investment) a technical project should cost to be perfect and future-proofed, and the ‘price’ an organization is prepared to pay at the time.”
Most digital projects are complex and broken down into manageable components, which tends to create multiple small technical debts. Taylor added, “Because we work in multi-product, constantly-changing organizations, it’s very easy for significant amounts of technical debt to mount up, piece by piece, and result in a large-scale incident which can cause a breach, a cyber attack or a business continuity incident.”
SEE: Business continuity policy (TechRepublic Premium)
Where does technical debt accumulate?
Next, Taylor addressed three areas of technical-debt accumulation that business and IT leaders need to monitor.
Redirected investments
Companies are fluid, redirecting finances and personnel to new products. Most companies are on tight budgets, and that usually means older products are not supported to the same level they were previously. To make matters worse, the older software in these products seldom plays nice with newer products and the latest operating systems, which results in security holes that cybercriminals are happy to find.
Redirected investments in money and personnel can affect current products. “We also see technical debt occurring in live products when an ideal development scenario will take significant time and investment, but a viable product can be created in a shorter timescale, even if it’s not perfect,” explained Taylor. “Finding this balance between perfection, appropriate functionality, and minimum viability is a challenge, and some can find themselves in a situation where improvements are promised once the project is complete, but then business priorities change, and the plans are not acted upon.”
Needless to say, managing technical debt is a challenge for upper management. Still, Taylor believes there is a sweet spot to be found: “…IT and business leaders need to work closely with development teams, setting clear objectives and helping create a product which is both satisfactory to the software developer, secure and low-risk, and acceptable to the leader keen to deliver a product within a limited timeframe.”
Physical technology
Hardware is another challenge altogether. Critical industries such as financial services and healthcare are known to integrate legacy systems with current digital services. “Critical infrastructure is often built on proprietary OT (operational technology), which, when connected to modern digital services, can open organizations up to risk,” noted Taylor. “Add into this mix the wealth of smaller firms which make up the supply chain to large enterprises, government or critical infrastructure, and you have a perfect storm of legacy and unsupported technology.”
People
Taylor feels personnel is a challenge, but in a way not often considered. Those who were battling Y2K bugs back in the day will understand.
He points out that plenty of active software systems have been around for decades and are maintained by workers who have decades of experience, coding skill sets (e.g., PERL vs. Python), and years of institutional knowledge.
SEE: These old programming languages are still critical to big companies. But nobody wants to learn them (TechRepublic)
The people who service, maintain and manage the older, hybrid technology and services are invaluable. “However, as businesses evolve over time, and leaders adapt strategies and redirect resources to new products and services, systems built on older code can be neglected,” wrote Taylor. “Organizational change can lead to people feeling disenfranchised, increasing the risk of insider threat–of particular import if they are managing critical IT infrastructure.”
The answer, according to Taylor, is to incorporate succession planning. Put simply, all workers eventually leave or retire, and unless there is knowledge sharing, the legacy systems will be maintained by employees who have very different skill sets–something cybercriminals would be happy to find.
How should IT leaders assess risk and manage technical debt?
The bottom line is developers need to build end-of-life procedures into every product and customer project from the very start. “When organizational change happens, so should risk assessments, documenting the potential impact on software and hardware, and putting contingency plans in place,” emphasized Taylor. “Even on technology which is on a path to end-of-life, some investment in both infrastructure and human resources must be provided.”
Final thoughts
Taylor reiterated the need to plan for change when developing new software: build for both scalability and future upgrade paths. He concluded with a comment I think Y2Kers will completely agree with: “We do need succession planning for software, or we risk continued misconfiguration or vulnerability-driven outages, breaches or cyberattacks.”
Also see
[ad_2]
Source link