When IT leaders think about “rip and replace” efforts, the first thoughts that probably come to mind are about the potentially huge cost and the inevitable disruption to the business. But these massive system replacement efforts also create different security worries for the organization.
The irony is that either the older system or the new system might be the better one from a basic security standpoint, determined in large part by how seriously the organization takes security from the outset. It can be a Catch-22 scenario that the CSO can do a lot to resolve.
A lot also depends on how complex each system is, what the business needs to do with each, and who will access each. That changes a lot according to how business processes evolve as a result of the effort. It can be an apples-to-oranges comparison.
“I don’t think there’s an obvious or clear cut answer, and the reason is this: when you talk about security as a result of a change, what you are actually asking is, ‘how secure is the new system as compared to the old system’, and ‘what kind of risks are being introduced as a result of a change to the system’?,” explains Michael Krigsman, an industry analyst and founder of CxOTalk.com.
“Typically, an older system may not be written as securely as a new system because in the ‘olden days’ we didn’t take security as seriously as we do today,” Krigsman notes. “On the other hand, that older system may be simpler than the new system and the footprint may be smaller, which means that there is less there to go wrong.”
“If it’s a modern system, the newer system should be architected from the ground up with security as a major concern,” Krigsman continues. “On the other hand, that new system is probably going to have interfaces to external partners and vendors, which is definitely an added layer of complexity and risk.”
Is there better safety in numbers?
How secure a replacement system is depends in part on whether organizations go it alone with rip and replace efforts; or, if a solutions provider is involved, which parts of the project they manage. Chances are that the organization doesn’t have many staff trained on the new system, and internal IT will have all it can do just to keep up with the implementation.
This makes the organization dependent on the vendor’s team to build security measures in properly, and that means from a user need perspective as well as technology one.
Security concerns also extend to the data itself and what will happen as the organization sunsets the old system, and goes live on the new one.
From the “rip” perspective, the organization needs to worry about where applications are housed; what data is stored with them; whether individual data will be migrated or destroyed during the transfer; what the destruction policies are for the old system; and whether targeted data will indeed be destroyed, explains Jody Albright, interim CIO at Providence Health Plan in Seattle, who managed a rip and replace effort in her previous job at Overlake Medical Center.
From a staff perspective, “It is much easier to handle data internally,” Albright notes.
From the “replacement” perspective, Albright advises CSOs to pay attention to how applications will be accessed; what data integration requirements they pose; if there is ‘special’ data within it (such as SOX or PHI); and what regulations are required around that data.
“Does the application security house, transfer, access, and display data appropriately,” Albright poses. “How does the application play within the firewall?”
Other security concerns with the new system and a vendor managing it include issues around authentification; password requirements; whether the system supports SSO; encryption of data transmission; disaster recovery capabilities; and the ability to work with security software and tools.
“The best way to address them is to ask the questions up front, identify the must-dos and the can-dos, and include them in the planning,” Albright says.
Asking the right questions at the right time
Asking those right questions up front and mapping out security from the outset is probably the most important role the CSO can play here. The development team probably has too much on their plate already to make security a top priority.
“Developers don’t have a very high awareness of security,” says Jim Duggan, research vice president in the Applications Strategy and Governance practice at Gartner. “They are pressed for time and if anything, they expect the business sponsor to set requirements explicitly enough that they can build to them. Given that the risk environment has gotten dramatically worse, if you’re going to rebuild something you’re probably going to want to build in security at the architecture stage as a fundamental process.”
Duggan also cautions that a vendor team doesn’t have the benefit of “tribal knowledge” about the client, as Duggan terms it. Security measures recommended by the vendor may not address important aspects of how the business actually works and employees go about their jobs.
“You’ve got to build a process that is going to get those concerns at least examined early, and then create a governance process that is going to have an advocate for security at least at the level that the requirements are set,” Duggan stresses.
“Whether it’s a waterfall or agile processes, someone has got to prioritize spending on security,” Duggan concludes. “If you leave it to the good intentions of the development team, they’re going to do something -- but probably not consistently, and probably not thoroughly.”
ALSO: Rip and replace: When it pays to make a total systems change