What are secure systems? Basically, as per Information technology best practices, Hosted systems are secured to minimize unauthorized access and possible tampering. Most people already know about server rooms (or data centers in larger organizations) allowing card-swipe only access with approved permit, escorted by personnel, limited access etc.
How about virtual access? To begin with, the systems should be built (I don’t mean physically built, but initialized or configured by the Systems Administrator – “build” is a common terminology in infrastructure areas for this process). There should be a SOP (Standard Operating Procedure) for building a server in a networked environment – and it should list all the must-have packages or software that the system must, at a minimum. These include basic I/O limited access, anti-virus and malware prevention, and limited or no insecure services (FTP, RSH in Unix systems) etc. Depending on the type of server being built (Web, database, application, middleware or other), special packages may be installed – for example, Tectia SSH package software might be installed on web servers to prevent user passwords from being communicated in clear text – in case the network and/or host is compromised, passwords in clear text could then be easily stolen and misused to cause much wider damage than the initial hacking.
Additionally, a checklist is often used to ensure that all the above mentioned processes were completed successfully and is signed and dated, either on a paper or electronic copy – these are considered official documents and may be requested (demanded?) from auditors.
Hosts (servers) should also ensure that access is limited to complete specific tasks by authorized personnel (and access through a configuration management system should require a request with complete details and approval by a manager and another group, say, Change control). Universal access (such as World writeable files and directories) should either not be allowed or kept to a minimum.
Functional IDs (“DB operator”, “SysAdmin1” etc) should also be allowed minimally or not at all as they cause tracking and auditing issues (“DB Operator” is much harder to track than “JSmith”).
Server logs should also be available, confidential and have data integrity – that is, not corrupted or incomplete – to the greatest extent possible. This is part of the “Confidentiality, Integrity, Availability” mantra of IT best practices. Log backup and retention and retrieval should conform to regulatory and corporate standards as well (here’s a question – how often are log backups tested – that is, retrieved and checked for completeness – other than during an audit?).
Developers’ access to production servers or data (known as DAP) is another area with conflicting demands. Security and Compliance policy generally dictates that developers not be able to access production data; but in the real world, developers are also in the line of support – often times, they may be the first level of support, especially if the application in question is very complex and is not established. Furthermore, the various levels of support may not have the in-depth expertise required to solve some urgent production problems. Anticipating this, an “emergency access to production” policy should be ready – at the least it should specify:
· The process for obtaining emergency access to production servers, data and logs
· Approval process (be realistic – if a developer offshore needs a senior manager’s approval at 4 am EST, what does he do?)
· Specific, time-bound parameters – access to say, production server DBPROD1 will last from time approved for 4 hours” and be limited to view only specific areas (e.g., “\app\bin\userlogs\”).
· Follow-up – once the issue has been resolved, follow-up communications and resolution items should be done by the owner of the process in question.
One note – the process above should generally try to avoid listing specific people’s names or contact numbers as these might change frequently – instead, a more useful email distribution list with a descriptive name such as “Emergency approvers for brokerage app 1” might work better.
Another issue dealing with privacy and data segregation is that developers often need access to huge volumes of real-world data to test various scenarios and parameters in their apps. To do so, they sometimes take production data (e.g., last week’s brokerage transaction master file). This is considered a breach of privacy as well as frowned upon by Auditors – a malevolent developer might take a real user’s details and possibly misuse it or send it to a friend outside the firm. Enter the ETL (Extract, Transform, Load) software – otherwise known as “data obfuscation” software. This would take all the data in a specified data file, and fudge the details so that real names, SSNs, and account numbers are masked by made-up data. This might be more suitable to larger organizations – the cost and complexity of enterprise level ETL software is high. Cheaper alternatives are also on the market though, and are getting better.
As networked systems grow more complex, they grow more vulnerable to mistakes and misuse - and the points above are a starting point for securing them.
No comments:
Post a Comment