Organizations running mainframe applications can substantially reduce costs and increase flexibility by moving portions of their mainframe workloads to the cloud. At Astadia, we often say that “Cloud is the new Mainframe”. After all, the cloud is highly scalable, capable of handling heavy workloads, and has the infrastructure necessary to ensure enterprise-grade security.
In some ways, though, the cloud is profoundly different from a mainframe environment. For starters, a mainframe system is fully under your control. Incoming and outgoing connections are well defined. Cloud environments, on the other hand, are generally highly inter-connected, and there are multiple dependencies that must be considered. Someone else owns the infrastructure and controls all of the incoming and outgoing connections.
How then should organizations approach security in a cloud environment? Ultimately, cloud security must always be viewed as a partnership; the environment is co-managed by you and the cloud provider together. But as the old saying goes, if everyone is responsible, then no one is responsible. This has profound implications for security. How can you ensure that responsibility for security is clearly articulated, communicated, and monitored?
As an organization, you are ultimately responsible for your reputation. A regular cadence of news stories on security breaches and privacy concerns stand as testimony to the cost of security failures. If a data breach occurs, it’s on you. If system availability is compromised, it is your brand that will suffer. Although shared responsibility is a reality, it is your good name that is on the line if anything goes wrong.
In an environment of increasingly rigorous regulation and oversight, it is you that will be held legally accountable as well. If your organization is found to be out of compliance, the financial penalties can be steep.
For years, SaaS companies have sold their product on the premise that customers could reduce or even eliminate many of the costs associated with managing their IT infrastructure. While that is true in some respects, it can be very dangerous to make too many assumptions about who is responsible for what. As many customers of SaaS applications have found out the hard way, even some of the simple things (such as backups) cannot necessarily be taken for granted.
The first step is to acknowledge who ultimately owns security. As we have already said, you do.
Once that is clear, the second step is to be sure that roles and responsibilities are clearly defined across the organizational boundaries, – particularly between the contracting organization (that is, you) and the cloud provider. Understand exactly what the cloud platform provider is doing on the security front. And for the reasons already cited, it is still your job to make sure that gets done.
Begin by making sure that your organization’s leadership, as well as the security team, understand the various critical business functions that are in play, as well as who owns them, and what the risks are. The security team must have a thorough knowledge of cloud deployment models, business processes, and legal compliance and privacy issues. They must also understand management’s level of tolerance for risk.
Learn more: Preparing a Disaster Recovery Strategy
For government agencies, there are well-defined guidelines that establish what is permissible and what is not. Security Technical Implementation Guides (STIGs) provide a framework for assessing an IT environment to ensure that it complies with the necessary security standards.
The Federal government makes those STIGs publicly available, and they are used by many organizations (even outside of the government sector) as a starting point for establishing sound security policies. Because they are updated regularly, they provide an excellent starting point for security best practices.
In some cases, however, a STIG policy may conflict with one or more applications. Under those circumstances, organizations that are legally required to follow STIG standards may apply for a waiver of specific policies to accommodate those kinds of exceptions.
Ultimately, such conflicts should be raised with software vendors so that applications can be brought into compliance with best practices for security.
New privacy regulations such as the European Union’s General Data Protection Regulation (GDPR), California’s Consumer Privacy Act (CCPA), and similar legislation elsewhere have prompted a range of new concerns and questions. Although GDPR has been around for several years now, there are still a number of questions yet to be resolved.
Many of those questions are wrapped up in the courts. The Schrems II court decision, for example, will have broad implications for any company doing business with residents of the European Union. The data sovereignty implications of that ruling concerns could have a profound impact on arrangements with cloud providers.
As the technology landscape continues to evolve, and as similar cases work their way through the courts, organizations will need to keep a close eye on the impact of such decisions on data sovereignty, privacy, and security.
Keep in mind, once again, that if your organization is found to be out of compliance with GDPR, or similar regulations elsewhere, then it is your company and brand that will suffer. You must ultimately own security and compliance.
For systems that are outside of your direct control, your cloud service provider or a third-party security company can bridge security practices between your on-premise systems and the cloud. We recommend that contracting organizations look for partnerships with organizations that:
In the end, responsibility for security and compliance ultimately falls to the contracting organization, – not the cloud provider. Cloud platform providers can perform part of the job, but you must be very clear about division of responsibilities, and understand where the lines are drawn.
You can delegate some portion of security to a cloud provider, or work with an experienced third party that will handle it for you. In either case, It is critical that your organization takes a holistic view of their IT landscape from a security perspective. Roles and responsibilities must be crystal clear.
Everybody agrees that automation is key to mainframe modernization regardless of the selected transformation approach, particularly in replatforming or refactoring projects. Not everybody, however, has the vision to automate the journey all the way.
COBOL talent shortage is a major mainframe modernization driver and that’s when every IT leader must make a decision about what will happen to the COBOL programmers in this scenario.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now