Consolidated Audit Trail (CAT) is live, what’s next?!

Consolidated Audit Trail (CAT) is live, what’s next?!

Compliance beyond Phase 2a/b – Top 5 things firms should be considering as they near initial go-live milestones.

It seems that the industry has resigned to the fact that CAT going live is no longer a matter of ‘IF’ but ‘WHEN’. FINRA’s ability to work through thorny issues and keep up with deliverables / promises to date has been proving the naysayers wrong. General view is that 2a will most definitely happen on time!

While the industry at large is working very hard to achieve go-live with successful testing and April 2020 go-live of 2a, this article aims to give firms time to pause and consider other critical items. The list is not exhaustive and there is no intention to cover the obvious challenges i.e. Phases 2c / d, Legal Entities and FDID, linkages, representative orders, customer data, error corrections, etc. That’s entirely a different topic and would require appropriate focus.

Regardless of your CAT solution (i.e. internal, vendor, etc.) the aim is to provide practical considerations that will yield appropriate fruits and make CAT implementation more accurate, meaningful, and sustainable.

Readiness Assessment

CAT implementation modification from ‘big bang’ to ‘phased out’ go-live has been of tremendous benefit to the industry, and according to some experts, CAT would not have been anywhere near as far along if not for this change. There is a tremendous opportunity for the industry to avoid a typical costly and draining ‘remediation process’.

With CAT there is a unique opportunity to take a pulse check very early on, as you progress through phases by conducting an independent ‘Health Check’, which will yield very important output, e.g. Inform soundness of current implementation, influence future controls, inform upcoming phases, and make overall change managements much more cohesive.

BAU Transition

Due to multiple go-live dates, the transition to BAU is not a trivial / typical exercise as it relates to CAT. The resources working on the immediate implementation will likely have to continue to roll out future phases. The strategy will be unique to each firm / size / location etc. To get you started, some low hanging fruits are: Knowledge transfer, documentation, training materials, regional ownership vs. follow the sun, initial headcount requirements and ways to scale as the scope grows, among others.

Controls

Controls are fabric that gives senior management, auditors, regulators some level of comfort to ensure accuracy, timeliness, and completeness when it comes to regulatory reporting. Unfortunately, controls are typically built in ‘hind-sight’ after a major flaw is uncovered or audit points out a specific weakness. Although, at times necessary, the sequence for building controls on the back of an incident is far from ideal. Firms should build solid controls unique to their implementation, ‘new business’ process and risk tolerance. Consider using independent tools to conduct some controls that can help your firm establish credibility in addition to benefiting from ‘crowd sourcing’ approach to controls and thereby avoiding a siloed viewpoint.

Service Level Agreements (SLAs)

One of the hot button topics for the industry is the ‘error correction cycle’ and its impact on ‘exception management’. Essentially firms will have 1 ½ days to correct errors (T+3 correction requirement is from Trade Date and FINRA will provide broker dealers with errors by 12pm next day). Drafting and finalizing SLAs with key players in the process (e.g. Middle Office, Trade Capture, Technology team, etc.) to make appropriate changes needed to facilitate a reasonable exception management and error corrections process is a very worthwhile exercise.

Traceability

With the passing of time, and natural attrition of your SMEs working on the implementation, knowing the ‘why’ ‘how’ ‘who’ ‘when’ as it relates to your program will be critical. It is inevitable that assumptions are made, unique rule interpretation specific to a business line are penned, and a bespoke code to deal with a unique problem are developed. It may be obvious now why something was done or implemented a certain way; it is NOT the case with the passing of time. Ensuring that you have clear traceability, evidence of sign off, approval of critical decisions, will not only shield your work and withstand the test of time, it will make the lives of people who own the process after you that much easier. Although this item will not show up for a very long time, eventually your due diligence will pay off and earn your work a solid reputation.

All in all, as with any other complicated topic, there are multiple other items that firms should be thinking about now i.e. Impact on surveillance, data lineage and governance, change management, etc. 5 that were covered above seem to be most practical to tackle at this stage, but you should NOT stop here! Wishing you a smooth implementation and a successful go-live!

Splunk vs. ELK – The Risk Focus Way

Splunk vs. ELK – The Risk Focus Way

Executive Summary

Though Splunk and ELK offer similar features, choosing the ideal solution for a specific enterprise depends heavily on the use-case being contemplated and the organization’s capacity to integrate and build on top of technology platforms.

Splunk offers robust commercial level support and a broader set of plugins/apps than ELK. These offerings can lower the effort required to integrate Splunk into an enterprise and use it across a broad set of use-cases. For organizations with narrower requirements, ELK offers a compelling solution, with support for numerous data sources with standard plugins and apps. ELK’s open source nature allows teams capable of developing plugin code to build an excellent customized solution on the ELK platform.

In this paper, we evaluate Splunk and Elastic (ELK) along criteria that are relevant to medium and large-scale organizations. These include ease of adoption, integration into a heterogenous compute environment, scalability, support for public cloud infrastructure monitoring, performance, total cost of ownership, and features relevant to use cases of value for our clients.

Read our other Splunk piece, relevant to the build for large-scale environments. Read More →

Contents

– Why aggregate logs?
– Executive Summary
– Feature Set Comparison
– Ingestion/Integration Add-Ons/Adapters
– Applications/Pre-built reports
– Performance
– Maintainability and Scaling
– Cloud Offering
– Support
– Ease of Use and Training
– Total Cost of Ownership/Use
– Conclusion

Authors

Subir Grewal

subir.grewal@riskfocus.com

Lloyd Altman

lloyd.altman@riskfocus.com

Cary Dym

cary.dym@riskfocus.com

Peter Meulbroek

peter.meulbroek@riskfocus.com

Tara Ronel

tara.ronel@riskfocus.com

Download the Whitepaper

About Risk Focus

We created Risk Focus in 2004, but our technical and leadership experience goes back much further. Our clients lean on us for our deep domain knowledge, unmatched technology expertise and fine-tuned problem-solving and delivery methodologies.

We have deliberately avoided breakneck growth, instead hiring only proven industry experts and curious, thoughtful technologists who are motivated by the variety and scale of the challenges they conquer in our client projects.

Data Masking: A must for test environments on public cloud

Data Masking: A must for test environments on public cloud

Eat your own cooking

Why mask data? Earlier this month, the security firm Imperva announced it had suffered a significant data breach. Imperva had uploaded an unmasked customer DB to AWS for “test purposes”. Since it was a test environment, we can assume it was not monitored or controlled as rigorously as production might be. Compounding the error, an API key was stolen and used to export the contents of the DB.

In and of itself, such a release isn’t remarkable; it happens almost every day. What makes it unusual is that the victim was a security company, and one that sells a data masking solution; Imperva Data Masking. This entire painful episode could have been avoided if Imperva had used their own product and established a policy to require all dev/test environments be limited to masked data.

The lesson for the rest of us is that if you’re moving workloads to AWS or another public cloud, you need to mask data in all test/dev environments. In this blog post, we will consider how such a policy might be implemented.

Rationale for Data Masking

Customers concerned about the risk of data loss/theft seek to limit the attack surface area presented by critical data. A common approach is to limit sensitive data to “need to know” environments. This generally involves obfuscating data in non-production (development, test) environments. Data masking is the process of irreversibly, but self-consistently, transforming data such that the original value can no longer be recovered from the result. In this sense, it is distinct from reversible encryption and has less inherent risk if compromised.

As data-centric enterprises move to take advantage of pubic cloud, a common strategy is to move non-production environments first; the perception is that these environments present less risk. In addition, the nature of the development/test cycle means that these workstreams can strongly benefit from the flexibility in infrastructure provisioning and configuration that public cloud infrastructure provides. For this flexibility to have meaning, dev and test data sets need to be readily available, and as close to production as possible so as to represent the wide range of production use cases. Yet, some customers are reluctant to place sensitive data in public cloud environments. The answer to this conundrum is to take production data, mask it, and move it to the public cloud. The perception of physical control over data continues to provide comfort (whether false or not). Data masking makes it easier for public cloud advocates to gain traction at risk-averse organizations by addressing concerns about the security of data in the cloud.

Additionally, regulations like GDPR, GLBA, CAT and HIPAA impose data protection standards that encourage some form of masking in non-production environments for Personal Data, PII (Personally Identifiable Information) and PHI (Personal Health Information) respectively. Every customer in covered industries has to meet these regulatory requirements.

Base Requirements

Masking solutions ought to provide some number of the following requirements:

  1. Data Profiling: the ability to identify sensitive data across data-sources (eg. PII or PHI)
  2. Data Masking: the process of irreversibly transforming sensitive data into non-sensitive data
  3. Audit/governance reporting: A dashboard for Information Security Officers responsible for meeting regulatory requirements and data protection

Building such a feature set from scratch is a big lift for most organizations, and that’s before we begin considering the various masking functions that a diverse ecosystem will need.

Masked data may have to meet referential integrity, human-readability or uniqueness requirements to support distinct test requirements. Referential integrity is particularly important to clients who have several independent datastores performing a business function or transferring data between each other. Hash functions are deterministic and meet the referential integrity requirement, but do not meet the uniqueness or readability requirements. Several different algorithms to mask data may be required depending on application requirements. These include:

  1. Hash functions: e.g., use a SHA1 hash
  2. Redaction: (truncate/substitute data in the field with random/arbitrary characters)
  3. Substitution: with alternate “realistic” values (a common implementation samples real values to populate a hash table)
  4. Tokenization: substitution with a token that can be reversed, generally implemented by storing the original value along with the token in a secure location

Data Masking at public cloud providers

AWS has several white-papers, reference implementations, including:

However, none of these solutions address masking in relational databases or integrate well with the AWS relational database migration product, DMS.

Microsoft offers both versions of its SQL Masking product on Azure:

  • Dynamic Masking for SQL Server: which overwrites query results with masked/redacted data
  • Static Masking for SQL Server: which modifies data to mask/redact it.

For the purposes of this discussion, we focus on what Microsoft calls “static masking” since “dynamic masking” leaves the unmasked data present on the DB, failing the requirement to shrink the attack surface as much as possible. We will also focus this discussion to AWS technologies to explore cloud-native versus vendor implementations.

Build your own data masking solution with AWS DMS and Glue

AWS Data Migration Service (DMS) currently provides a mechanism to migrate data from one data source to another, either at one time or via continuous replication as described in the diagram below (from AWS documentation):

Build your own data masking solution with AWS DMS and Glue

DMS currently supports user-defined tasks that modify the Data Definition Language (DDL) during migration (eg. dropping tables or columns). DMS also supports character level substitutions on columns with string type data. A data masking function using AWS’ ETL solution Glue could be built to fit into this framework, operating on field level data rather than DDL or individual characters. An automated pipeline to provision and mask test data-sets and environments using DMS, Glue, CodePipeline and CloudFormation is sketched below:

Build your own data masking solution with AWS DMS and Glue

When using DMS and Glue, the replication/masking workload is run on AWS, not in the customer’s on-premises datacenter. Un-masked or un-redacted data briefly exists in AWS prior to transformation. This solution does not address security concerns around placing sensitive data (and accompanying compute workloads) on AWS for clients who still gingerly approach public clouds. Still, for firms that look for a cloud-native answer, the above can form a kernel of a workable solution, when combined with additional work around identification of data needing masking and reporting/dashboarding/auditing.

Buy a solution from Data Masking Vendors

If the firm is less concerned about cloud-native services, there are several commercial products that offer data masking in various forms which meet many of these requirements. This includes IRI Fieldshield, Oracle Data Masking, Okera Active Data Access Platform, IBM Infosphere Optim Data Privacy, Protegrity, Informatica, SQL Server Data Masking, CA Test Data Manager, Compuware Test Data Privacy, Imperva Data Masking, Dataguise and Delphix. Several of these vendors have some form of existing partnership with cloud service providers. In our view, the best masking solutions for the use case under consideration is the one offered by Delphix.

Buy: Data Masking with Delphix

This option leverages one of the commercial data masking providers to build data masking capability at AWS. Delphix offers a masking solution on the AWS marketplace. One of the benefits of a vendor solution like Delphix is that it can be deployed on-premises as well as within the public cloud. This allows customers to run all masking workloads on-premises and ensure no unmasked data is ever present in AWS. Some AWS services can be run on-premises (such as Storage Gateway), but Glue, CodeCommit/CloudFormation cannot.

Database Virtualization

One of the reasons Delphix is appealing is the integration between its masking solution and its “database virtualization” products. Delphix virtualization lets users provision “virtual databases” by exposing a filesystem/storage to a database engine (eg. Oracle) which contains a “virtual” copy of the files/objects that constitute the database. It tracks changes at a file-system block level, thus offering a way to reduce the duplication of data across multiple virtual databases (by sharing common blocks). Delphix has also built a rich set of APIs to support CI/CD and self-provisioning databases.

Delphix’s virtualized databases offer several functions more commonly associated with modern version control systems such as git. This includes versioning, rollback, tagging, low cost branch creation coupled with the ability to revert to a point along the version tree. These functions are unique in that they bring source code control concepts to relational databases, vastly improving the ability of CI/CD pipeline to work with relational databases. This allows users to deliver on-demand, masked data to their on-demand, extensible public cloud environments.

A reference architecture for a chained Delphix implementation utilizing both virtualization and masking would look like this:

Database Virtualization

Conclusion

For an organization with data of any value, masking data in lower environments (dev, test) is an absolute must. Masking such data also makes the task of migrating dev and test workloads to public clouds far easier and less risky. To do this efficiently, organizations should build an automated data masking pipeline to provision and mask data. This pipeline should support data in various forms, including files and relational databases. Should the build/buy decision tend toward purchase, there are several data masking products that can provide many of the core masking and profiling functions such a masking pipeline would need, and our experience has led us to choose Delphix.

Consolidated Audit Trail (CAT) resurrects the age-old question ‘Build vs. Buy?’

Consolidated Audit Trail (CAT) resurrects the age-old question ‘Build vs. Buy?’

Well, like any other complicated problem there isn’t a ‘one size fits all’ answer. Multiple variables will be at the heart of your decision making, including your firm’s scope, long-term strategy, maintenance, etc. Hopefully below will give your firm some guidance on things to consider making the right strategic decision.

Case for working with a dependable vendor:

Price: Your budget will likely be a #1 driver. Cost that will be associated with building an in-house solution will likely far exceed a pre-determined solution. Depending on your size, it may be economical to give up convenience of proprietary built vs. out of the box solution.

Time: Conforming with expected regulatory timelines is critical, both from reputational standpoint and having to avoid a potential regulatory fine/action. Possibility of slippage is a reason enough for you to consider a vendor solution.

Industry knowledge: SME knowledge is not replaceable, but where proficiency is lacking utilizing a vendor may be optimal way to go to market. A reputable vendor will ensure the solution aligns to the actual rule and regulator’s expectations.

Scale: Overtime the vendor will receive continuous feedback as it relates to the solution, and economies of scale will dictate that their solution will continue to improve and serve your broader needs.

Reasons to consider looking to internal solution:

Accountability: Don’t confuse ‘service offering’ that meets your needs with your obligations. Just because you are utilizing a given solution that seems to ‘work’, it doesn’t alleviate your overall responsibility for the accuracy of the reporting. ‘Safety in numbers’ will not work when external audit is conducted.

Ongoing maintenance: Going with a vendor is never truly ‘plug n’ play’. You will have to ensure you implement and deploy the solution. Involvement and scope will depend on size/needs of your firm.

Limitations: You will find yourself locked into the solution and proposal that aims to address broader needs but may not be customizable to your specific business and overtime may generate unwanted limitations which will be difficult to overcome.

Cost: up-front price may be attractive but consider the longevity and ongoing dependability. Price point shouldn’t be limited to ‘go-to-market’ mentally.

In Conclusion

Overall, in-house built is not replaceable, but it may be more practical to consider outside solutions. The decision is never one dimensional and never in the moment, as it will transcend scope and time. Your decision should balance practical short-term considerations and long-term strategy/vision.

RegTek.Solutions (a Bloomberg company) – Redesigning on AWS to Offer SaaS

Abstract

Client: RegTek Solutions

Project Dates:  January 2017 through May 2017

Technology Solutions Used:

  • Jenkins
  • Ansible
  • OneLogin for authentication and authorization of client users
  • DataDog for monitoring

Summary

RegTek.Solutions (a Bloomberg company) is one of the premier software providers in the Regulatory Reporting space, serving 15 of the 20 largest global banks as customers.  Their software was developed to run inside a data center, but customer demand required them to provide a SaaS offering in addition to an option running in customers’ own data centers.  Leveraging the flexibility of AWS, Risk Focus quickly adapted the platform to run in the cloud and introduced new automation while decreasing time-to-market and reducing time to onboard new customers.

Due to business developments, we needed to evacuate our data center very quickly. Risk Focus helped us make this move while re-engineering our development and deployment processes. This allowed us to become more agile and increase delivery velocity. Moreover, they helped us deliver our first SaaS offering and onboard our first clients to the new platform.  Risk Focus’s key differentiator is their unique combination of deep Financial Services domain knowledge coupled with technical expertise and delivery excellence.

Brian Lynch

CEO, RegTek.Solutions (a Bloomberg company)

Problem Statement

The RegTek software was originally developed to be tested and run inside a data center as binary artifacts, with VMs running on a small set of Hyper-V racks in the client’s own data centers.  After initial launch, many of them asked for a SaaS solution, and so RegTek needed to move the platform to the cloud while maintaining the ability for it to run locally within a data center.

RegTek enlisted Risk Focus to help:

  • Create a fully-automated CI/CD pipeline outside of its data center that would allow it to provision environments on demand, build the binary artifacts, and run large-scale testing on its suite of products
  • Develop a process to produce different deployable binary artifacts, both traditional wars and Docker containers
  • Create a secure automated SaaS offering for current and prospective customers
  • Onboard its first batch of clients onto the newly-built SaaS platform

 

AWS-Based Solution

We proposed that RegTek move to AWS, but because its software needed to retain the ability to run in any data center, we ensured that the software was cloud portable and not tightly bound to the AWS cloud native offerings. The elasticity provided by AWS allowed RegTek to develop and test much faster by provisioning and tearing down environments in an automated way.

We then deployed some of the RegTek products as SaaS offerings into separate AWS accounts under an Organization, leveraging Consolidated Billing.

The solution involved provisioning single-tenant VPCs with Oracle instances for each client, which were created by using CloudFormation templates. Because of the sensitivity of the data being reported, all SaaS clients had requested complete isolation from one another.

In the new design, CloudWatch was implemented to capture all logs, and CloudTrail to monitor access to all deployed resources.  Resiliency was achieved by relying on ELB, Multi-AZ deployments, and Auto-scaling groups.

 

Financial Services Domain Expertise

The project consisted of three components: developing CI/CD pipelines, re-designing the architecture to offer SaaS, and onboarding customers onto the new SaaS platform.  Risk Focus’s keen domain knowledge of trading risk and regulator compliance was especially useful in the last piece.

RegTek.Solutions enlisted Risk Focus to do all initial customer onboarding, where our Business Analysts identified clients’ required feeds and designed their delivery processes.  Risk Focus also used its deep domain expertise to map required data and enrichment to ensure that the raw trading feeds delivered by the client could be submitted to the SDR (Swaps Data Repository) of the DTCC.

More Options, Better Customer Service

RegTek.Solutions now operates a highly successful business that features both installations within customers’ data centers and a robust SaaS reporting solution hosted on AWS.  This allows RegTek to provide a higher value of service to their clients. It also allows their clients to focus on growing their Financial Services businesses, while staying compliant and avoiding the hefty fines levied on businesses that do not provide accurate and timely reporting.

Confluent Recognizes Risk Focus as a Preferred Professional Services Partner

Confluent Recognizes Risk Focus as a Preferred Professional Services Partner

For Immediate Release
Tara Ronel
June 7, 2019
tara.ronel@riskfocus.com

[New York, NY, June 7, 2019] – Risk Focus, a leading consultancy for highly-regulated industries, is proud to announce that it has earned Preferred status in the Confluent Partner Network Program, the enterprise event streaming platform pioneer.

VAssil

As a Confluent Preferred Partner, Risk Focus has met all the stringent business and technical program requirements, including significant customer development, training and certification of their staff. They have also demonstrated the required skill sets to help its financial services customers implement Apache™ Kafka™ and the Confluent platform in order to harness its flexible event streaming power in new or existing applications.

“We have invested heavily to develop our team through hands-on enterprise project experience, process implementation, Kafka courses and Confluent certifications,” shares Vassil Avramov, Founder and CEO of Risk Focus. “Confluent is, by far, the leader in the event streaming space, and we are thrilled to be nominated to a very small group of Confluent Preferred organizations. We recognize that this is only the beginning, and are committed to jointly helping our customers unlock the power of their data for years to come.”

“Financial services organizations are among the most impacted by the the effects of the digital revolution where technology and data are becoming key for remaining relevant to customers.  That is why so many are turning to event streaming platforms to power their applications to deliver the modern banking experiences customers expect. As the demand from this sector grows, it is important to have fully-trained and experienced Preferred Partners like Risk Focus assisting financial services organizations deploy solutions based on Confluent Platform to deliver contextual event driven applications.”“We have invested heavily to develop our team through hands-on enterprise project experience, process implementation, Kafka courses and Confluent certifications,” shares Vassil Avramov, Founder and CEO of Risk Focus. “Confluent is, by far, the leader in the event streaming space, and we are thrilled to be nominated to a very small group of Confluent Preferred organizations. We recognize that this is only the beginning, and are committed to jointly helping our customers unlock the power of their data for years to come.”

Vassil Avramov

Founder and CEO, Risk Focus

Confluent provides a complete event streaming platform based on Apache Kafka and extends Kafka’s capabilities with development, connectivity and stream processing capabilities as well as management and operations. The Confluent Partner ecosystem is an important element to drive success with customers to assist customers in developing robust data connectivity, building stream processing applications and ensuring the ongoing success of our joint customer’s strategic initiatives.

“Financial services organizations are among the most impacted by the the effects of the digital revolution where technology and data are becoming key for remaining relevant to customers” said Simon Hayes, vice president of corporate and business development, Confluent. “That is why so many are turning to event streaming platforms to power their applications to deliver the modern banking experiences customers expect. As the demand from this sector grows, it is important to have fully-trained and experienced Preferred Partners like Risk Focus assisting financial services organizations deploy solutions based on Confluent Platform to deliver contextual event driven applications.”

“Financial services organizations are among the most impacted by the the effects of the digital revolution where technology and data are becoming key for remaining relevant to customers.  That is why so many are turning to event streaming platforms to power their applications to deliver the modern banking experiences customers expect. As the demand from this sector grows, it is important to have fully-trained and experienced Preferred Partners like Risk Focus assisting financial services organizations deploy solutions based on Confluent Platform to deliver contextual event driven applications.”

Simon Hayes

Vice President, Corporate and Business Development, Confluent

###

About Risk Focus

Risk Focus is a NYC-based company that provides strategic IT consulting to global enterprises. The company’s Infrastructure practice provides solutions, methodologies, and strategic guidance for digital transformation, containerization, and automation. Its Financial Services team offers strong domain expertise and technology acumen to deliver feature-focused solutions in Capital Markets. To learn more about Risk Focus, please visit www.riskfocus.com.