Vice President, APACTommi serves as Vice President, APAC and is responsible for sales, business development and channel operations for the region. During his 15 years at the company, Tommi has worked as a product manager for multiple network encryption, authentication, and security management solutions.
Prior to SSH Communications Security, Tommi was an Information Management Engineer at Rautaruukki, a large Finnish steel corporation. He has an masters degree in engineering from the Tampere University of Technology, Finland and carries a CISSP certification.
Monetary Authority of Singapore (MAS) revised its Technology Risk Management Guidelines (TRM) in June 2013. Financial Institutions (FI) operating in Singapore have since been reviewing the guidelines against their own security procedures and infrastructures, to determine necessary enhancements to match the new requirements. While the guidelines are not legally binding, MAS uses them when performing risk assessments of the FI.
The guidelines themselves are a holistic and quite sensible set of high-level guidance on the processes, controls, and responsibilities necessary for implementing system security, and for protecting customer and financial data – a constant target for malicious activities. The guidelines are mostly technology-agnostic, as MAS does not want to dictate technology specifics, leaving actual implementation choices to the institutions themselves. This approach, while sensible, leaves much leeway for the interpretation of how the guidelines apply to specific infrastructures within the FI environments. It also requires a deep understanding of the mechanisms and aspects of multiple layers of IT infrastructure. This poses a challenge for upper management and auditors, as implicit assumptions about both the requirements and the infrastructure itself may lead to severe oversights and gaps in the enforcement of access controls. I will continue to suggest some of these potential pitfalls:
MAS TRM Guideline 6.2.5 states that the FI should maintain separate physical or logical environments for unit, integration, as well as system and user acceptance testing, and closely monitor vendor and developers’ access to UAT environment. Similar requirements on the segregation of production, development, and testing environments can be found also in other security policy or compliance mandates. When examining the access controls and entry points between such logical environments, much emphasis is often put on interactive human users, and typical authentication methods such as passwords and management thereof. This approach easily overlooks the methods often used by developers for accessing IT environments, as well as for replicating code or software packages to target servers – such as using SSH key pairs for easy non-interactive authentication, either for manual access or for automated file transfer processes. SSH authorized keys may easily be left behind on servers, with the corresponding access granting private key left in the development environment, or in the hands of an external third-party vendor or IT resource. This creates an undocumented access path into the production or development environment, violating the high level requirement to segregate the environments.
Guideline 9.1.2 instructs that a comprehensive data loss prevention (DLP) strategy should be developed to protect confidential and sensitive data. A similar requirement is posed in guideline 9.6.2: The FI should implement network surveillance and security monitoring procedures with the use of network security devices, such as intrusion detection and prevention systems… Encrypted channels such as SSH provide further challenges for DLP solutions, and other network security components, such as firewalls, and IDS/IPS – as these cannot inspect the contents of the encrypted channel. This poses a severe gap in the security posture of the organization, as encrypted channels are commonly used by privileged users and carry sensitive data, and thus may be misused as a covert channel to both breach the environment, as well as to exfiltrate stolen data. Guideline 11.0.1 provides guidance on three basic security principles: a) Never alone principle, b) Segregation of duties principle, c) Access control principle. Section 11 goes on to present further guidelines on User Access Management. Again, the tools system administrators and external vendors use to execute their daily tasks over encrypted networks pose challenges for the effective implementation of these principles. Access controls and related management solutions often focus on managing limited modes of user access and authentication, such as password management. This approach may ignore the capability of administrators to generate and deploy their own SSH key-pairs to provide seamless authentication to target servers. While this is usually done for the sake of convenience and not out of malice, these undocumented key-pairs, and the capability to deploy them without supervision or approval processes, lead to a failure to meet several of the requirements in Section 11.
The above are some examples of how a ubiquitous technology, such as SSH, that administrators use to carry out their daily work, can provide severe challenges for auditors and organizations under compliance mandates – if their capabilities are not fully recognized when assessing the controls that are meant to ensure security and compliance within a FI.
I invite anyone responsible for meeting requirements such as MAS TRM, to have a chat with our experienced teams, who work with major financials across the globe on meeting their compliance and security goals – and to learn more about the tools and processes that can help to identify potential gaps in existing controls and environments.