Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Rip and replace can create security issues

David Weldon | Jan. 11, 2016
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.

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.


Previous Page  1  2 

Sign up for Computerworld eNewsletters.