Compliance

FundCount has partnered with Digital Edge in the AWS realm to provide a wide range of DevOps and SysOps services to FundCount SaaS clients. Digital Edge successfully collaborated with FundCount to architect, deploy, and support the award-winning Accounting, Analysis, and Reporting software hosted on AWS.

If your company is based in the EU, then the question of whether the GDPR applies to you is easy; it does.

But that is not all. 

Why HITRUST?  

HITRUST develops risk and compliance management frameworks, assessment, and assurance methodologies, maintains them, and provides access to them, being in collaboration with the leaders of information security and risk management, both from the public and private sectors. HITRUST aims to fill the gaps still not addressed by some regulations.

HITRUST Common Security Framework addresses security, privacy, and regulatory challenges organizations face. HITRUST includes and cross-references numerous globally recognized standards, follows a risk-based approach, and creates the options for a well-orchestrated unified method of managing data protection compliance. This makes HITRUST highly beneficial for those organizations seeking to safeguard the data, but this also makes HITRUST not easily implementable for those businesses that still require staff training and bringing all the processes to higher standards to implement HITRUST. Digital Edge is the right partner in achieving this goal.

Why OSPAR? 

Financial institutions rely heavily on outsourced service providers (OSPs) to assist with key business objectives.  

As financial institutions are ultimately responsible for the service provided to their customers, OSPs must comply with the standards and controls accepted within the financial industry.  

The Association of Banks in Singapore has established the Guidelines on Control Objectives and Procedures for all OSPs desiring to work with the numerous financial institutions in Singapore. To demonstrate your organization’s ability to meet these guidelines, an Outsourced Service Provider Audit Report (OSPAR) attestation is mandatory. Without an OSPAR attestation, your organization will not be able to provide services to the rapidly growing number of financial institutions in Singapore.  

Digital Edge will ensure that your organization will receive an OSPAR attestation as proof that it has implemented adequate cybersecurity safeguards to maintain the governance and consistency required. With OSPAR, your company will be ready to conduct business, and guarantee the security of your client’s critical information.

Digital Edge is proud to announce that we successfully assisted and obtained an OSPAR certification for one of our FinTech clients. 

What is OSPAR? OSPAR (Outsourced Service Providers Audit Report) is a report that can only be issued by one out of 5 accredited auditors. It is a critical pre-requisite for the 3rd party vendors, to demonstrate their adherence to stringent guidelines & best practices if they wish to conduct business in Singapore.  

Usually my blog posts are focused on the arguably mundane practices of cybersecurity governance. Today, though, I would like to get into something a bit spicier. Right now, as I write this, Russia has about 90,000 troops amassed at the Ukrainian border, and China has been harassing Taiwanese airspace for months. Some kind of aggressive action, possibly cyber-related, seems very possibly forthcoming; and with it, likely a response in kind.
 
It’s a known fact that Russia, China, North Korea, Iran and others engage in regular cyber attacks against the other countries including the US. We see this all the time. What I think is unclear to most people are the rules governing the responses to such attacks. Below I discuss a broad overview of how cyber attacks are handled by governments around the world.
 
First off, you should know that the international law around the rights self defense of a state actor is extremely murky and highly disorganized. Furthermore, different countries disagree on the interpretation of laws that exist. That being said, there are some general rules that are followed by responsible governments.

One regulation we help clients with is the New York State DFS 23 NYCRR Part 500 compliance.
 
Who does DFS regulate?

According to its website: “DFS is the primary regulator for all state-licensed and state-chartered banks, credit unions, and mortgage bankers and brokers. All mortgage loan servicers doing business in New York State must be registered or licensed by DFS. The Department also oversees all of the insurance companies operating in New York, licenses all of the budget planners, finance agencies, check cashers, money transmitters, and virtual currency businesses operating in New York.”
 
The requirements of part 500 are generally nothing out of the ordinary, or rather, nothing more than what is already considered good practice in the cybersecurity world.

POSITION ON RISK

1. Initial risk is 100% (99.9%). I argue, if you deploy a system without any controls and connect it to the internet, it will be hacked multiple times in a year.
2. Risk = 100% - control mitigation + destabilizing events (zero days, new vulnerabilities).
3. We may calculate control mitigation but cannot predict those destabilizing events, and this is the nature of the business, and this is why we cannot precisely measure risks. So we don't have to; we can just assess.
4. Mitigation is NOT lowering the impact but lowering LIKELIHOOD. When there is a cybersecurity breach, it is easier to predict maximum impact, which depends on the time of detection (controls - destabilizing). I would argue that within some short time, the impact could be the cost of the business. 
5. My biggest problem with current frameworks is that they all concentrate on initial assessment, not the continuous process.
6. Risk has to be re-assessed yearly, and the methodology is more important for re-assessment compared to the initial assessment.
7. Incidents should be used to adjust risks as it is real-life data for statistical analysis for the given client. Incidents should be used to re-assess likelihood, and each incident must be bound to a risk and effect KPI.
8. Methodology should suggest KPI assignment. 

This is the big picture. All I see today is ISO-like risks analyses that are initially made based on industrial risks. The mentality should be changed, and I don't know if it is too big of a shift from the current approach.