Ten years ago, for the second EIC, we published a report and survey on the intersection of IAM and SOA (in German language). The main finding back then was that most businesses don’t secure their SOA approaches adequately, if at all.
Ten years later, we are talking Microservices. Everything is DevOps, a small but growing part of it is DevSecOps. And again, the question is, whether we have appropriate approaches in place to protect a distributed architecture. This question is even more important in an age where deployment models are agile and hybrid.
So how to do IAM for this microservices world? Basically, there are two challenges: supporting the environments and supporting the services and applications.
The former are about securing containers. That includes privileged access to the environments the containers run in as well as the containers itself, but also the fine-grained access management and governance of such environments. It also includes the interesting challenge of segregating access to development, test, and production in the DevOps world, which is an even more demanding task than in traditional IT.
The second challenge is about how to secure communication between microservices. One of the technologies that inevitably comes into play here is API Management & Security. Beyond that, we will have to rethink authorization for services, but also how to manage and govern identities and their access at both the level of individual microservices and the orchestrated services and applications provided to the business.
Reasonably defined microservices, fully encapsulated and providing their functionality to connected services and applications exclusively via secure, authenticated and auditable APIs, are an important step towards secure architectures “by design”.
Notably, we must also start thinking about deploying security components as services, externalizing and standardizing them. I discussed this topic a while ago in a webinar – you might want to watch the webcast. With moving to a more agile approach of IT, where changes are quickly deployed to production environments, identity and security must become adequately agile. Automation becomes key to success. We see some interesting trends and offerings arriving, however most of them currently are focused on privileged users – which is a good start, but by far not the end of our journey towards secure microservices architectures.
It’s about time to make our IAM services ready to support the new way IT is done: agile and modular. Otherwise we will end up in a security nightmare.
Since I’m observing the IAM business, it has been under constant change. However, there is a change on its way that is bigger than many of the innovations we have seen over the past decade. It is IAM adopting the architectural concept of microservices.
This will have a massive impact on the way we can do IAM, and it will impact the type of offerings in the market. In a nutshell: microservices can make IAM far more agile and flexible. But let’s start with the Wikipedia definition of Microservices:
Microservices is a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. [Source: Wikipedia]
Basically, it is about moving to loosely coupled services and lightweight protocols for integration. Factually, this also includes lightweight APIs these services expose. Each microservice delivers specific, defined capabilities, which are then orchestrated.
When we look at the evolution of the IAM market, most applications have been architected more or less monolithic in the past. Most of them have some “macroservice” model built-in, with a couple of rather large functional components such as a workflow engine or an integration layer. Some vendors already have come a bit further in their journey towards microservices, but when looking at today’s on-premises solutions for IAM, for most vendors the journey towards microservices has just started, if at all.
Looking at IDaaS (Identity as a Service), the situation is different. Many (but not all) of the IDaaS solutions on the market have been architected from scratch following the microservices approach. However, in most cases, they do so internally, while still being exposed as a monolithic service to the customer.
The emerging trend – and, even more important, the growing demand of customers – now is for IAM being delivered as a set of microservices and via containers (which might contain multiple microservices or even a few legacy components not yet updated to the new model). Such an approach allows for more flexible deployments, customization, integration, and delivers the agility businesses are asking for today.
From a deployment point of view, such architecture gives business the option to decide where to run which of the services and, for example, support a hybrid deployment or a gradual shift from on-premises to private cloud and on to public cloud.
From a customization and integration perspective, orchestrating services via APIs with IAM services and other services such as IT Service Management is more straightforward than coding, and more flexible than just relying on customization. Lightweight APIs and standard protocols help.
Finally, a microservice-style IAM solution (and the containers its microservices reside in) can be deployed in a far more agile manner by adding services and orchestrations, instead of the “big bang” style rollout of rather complex toolsets we know today.
But as always, this comes at a price. Securing the microservices and their communication, particularly in hybrid environments, is an interesting challenge. Rolling out IAM in an agile approach, integrated with other services, requires strong skills in both IT and security architecture, as well as a new set of tools and automation capabilities. Mixing services of different vendors requires well-thought-out architectural approaches. But it is feasible.
Moving to a microservices approach for IAM provides a huge potential for both the customers and the vendors. For customers, it delivers flexibility and agility. They also can integrate services provided by different vendors in a much better way and they can align their IAM infrastructure with an IT service model much more efficiently.
For vendors, it allows supporting hybrid infrastructures with a single offering, instead of developing or maintaining both an on-premises product and an IDaaS offering. But it also raises many questions, starting with the one on the future licensing or subscription models for microservices – particularly if customers only want some, not all services.
There is little doubt that the shift to microservices architectures in IAM will significantly affect the style of IAM offerings provided by vendors, as it will affect the way IAM projects are done.
During yesterday’s opening keynote at the EIC (European Identity & Cloud Conference), I brought up (and explained) a slide about the areas where Blockchain technology has the potential of helping solving existing identity problems, either by doing it just better than today or delivering entirely new capabilities. Notably: it was about the potential, not that this will inevitably happen.
Not surprisingly – an Opening Keynote should provoke thoughts and discussions – this lead to some discussions in the social media right after. Some found that I’m gone over the top with that slide. Honestly, I don’t agree – not, when following what I’ve said. Yes, if I would have stated that all these things are already getting better or will definitely and inevitably get better, that would have been over the top. But factually, I don’t believe that there is any single area marked green in that chart where I’m wrong in predicting a potential for improving what we do in identity with Blockchain technology and where Blockchain (or, even broader, Distributed Ledger technology) has a potential for solving some of the open challenges we are facing around identity.
Let’s just look at the left-hand side of the slide. Identification is something outside of technology, unless we are talking DNA. Verification is straightforward – there are so many KYC (Know Your Customer) use cases based on Blockchain these days, with valid business models, that this is already reality or at least close to becoming reality.
Authentication might definitely become simpler, by having various authenticators and IDs, from eIDs to social logins, associated with a wallet. Just one simple store to get access. Yes, there are challenges in creating secure, easy-to-use wallets, but there is potential as well.
Authorization and smart contracts, privacy and smart contracts: obvious potential.
Auditing: there was a cool use case presented by T-Mobile US in that space the evening before during the Blockchain ID Innovation Night.
And finally, all the use cases on the right-hand side are ones closely related to what is discussed as the potential of Blockchain.
Simply said: for all these areas, Blockchain (ID) technology delivers a potential of solving challenges better. Whether someone can deliver on that potential, is a different story. But there is potential.
And to be very clear: we should not search for problems where we can apply Blockchain as a solution. But in the broad field of identity, we have masses of challenges where Blockchain, as one element of the solution, has a potential to solve the problems. We shouldn’t ignore that potential. Time to think beyond, I’d say.
When new things arrive, which are still in the pioneering stage and far from reaching maturity, there is always a lot of discussion. This is even more true for Blockchain Identity, where the massive hype around Blockchains, a long history of clever ideas failing, and a few interesting technical and security challenges come together. During my keynote at this year’s EIC, I addressed the challenges and success factors for Blockchain ID as well. That led to a discussion on Twitter about whether some of these success factors are contradictory.
That definitely is a good question worth thinking about. So where might be the contradiction lie?
- Critical mass vs. interoperability? No conflict.
- Critical mass vs. easy-to-use or secure wallets? No conflict.
- Critical mass vs. affordability? No conflict?
- There is anyway no conflict with Privacy by Design and Security by Design.
Anyway, if I make such pair-wise comparisons, I don’t find any obvious contradictions. I might have overlooked some, of course.
Obviously, there are some major challenges. Cyberattack resilience vs. cost vs. usability is not super-easy to achieve. That is why it is a challenge.
One factor where we definitely might have a discussion whether this is a contradiction in itself is the “easy-to-use, easy-to-secure wallet”. Making things both secure and easy to use is a challenge in itself, and it is a success factor for Blockchain ID in general, I admit it.
However, while it is not easy, I doubt that this is impossible, i.e. contradictory in itself. We have seen many improvements in usability of more secure solutions in the past years. Fingerprint biometrics might not be perfect, but it is better than 4-digit PINs. And it is quite easy to use. And that is just one example. In other words: there are ways to combine an acceptable level of usability with good-enough security. Yes, you can always use security as the killer argument. But we also know that there is no 100% security – it is always about finding the right balance.
But what we really should do is actually quite easy: stop arguing what might hinder us in delivering better identity solutions and start figuring out how we can deliver them by using Blockchain technologies wherever appropriate, combining it with what we already have (Identity Relationship Management, OpenID Connect, UMA, PKI, whatever else), and joining our forces.
As we all know, there is no better way for a security researcher to start a new week than to learn about another massive security vulnerability (or two!) that beats all previous ones and will surely ruin the IT industry forever! Even though I’m busy packing my suitcase and getting ready to head to our European Identity and Cloud Conference that starts tomorrow in Munich, I simply cannot but put my things aside for a moment and admire the latest one.
This time it’s about email encryption (or rather about its untimely demise). According to this EFF’s announcement, a group of researchers from German and Belgian universities has discovered a set of vulnerabilities affecting users of S/MIME and PGP – two most popular protocols for exchanging encrypted messages over email. In a chain of rather cryptic tweets, they’ve announced that they’ll be publishing these vulnerabilities tomorrow and that there is no reliable fix for the problems they’ve discovered. Apparently, the only way to avoid leaking your encrypted emails (even the ones sent in the past) to malicious third parties is to stop using these encryption tools completely.
Needless to say, this wasn’t the most elegant way to disclose such a serious vulnerability. Without concrete technical details, which we are promised not to see until tomorrow, pretty wild speculations are already making rounds in the press. Have a look at this article in Süddeutsche Zeitung, for example: „a research team… managed to shatter one of the central building blocks of secure communication in the digital age“. What do we do now? Are we all doomed?!
Well, first of all, let’s not speculate until we get exact information about the exploits and the products that are affected and not fixed yet. However, we could try to make a kind of an educated guess based on the bits of information we do have already. Apparently, the problem is not caused by a weakness in either protocol, but rather by the peculiar way modern email programs handle multipart mail messages (those are typically used for delivering HTML mails or messages with attachments). By carefully manipulating invisible parts of an encrypted message, an attacker may trick the recipient’s mail program to open an external link and thus leak certain information about encryption parameters. Since attacker has access to this URL, he can leverage this information to steal the recipient's private key or other sensitive data.
How to protect yourself from the exploit now? Well, the most obvious solution is not to use HTML format for sending encrypted mails. Of course, the practicality of this method in real life is debatable – you cannot force all of your correspondents to switch to plain text, especially the malicious ones. The next suggestion is to stop using encryption tools that are known to be affected (some are listed in the EFF’s article) until they are fixed. The most radical method, obviously, is to stop using email for secret communications completely and switch to a more modern alternative.
Will this vulnerability fundamentally change the way we use encrypted email in general? I seriously doubt it. Back in 2017, it was discovered that for months, Microsoft Outlook has been sending all encrypted mails with both encrypted and unencrypted forms of the original content included. Did anyone stop using S/MIME or decide to switch to PGP? Perhaps, the researchers who discovered that bug should have used more drama!
Yes, however negatively I usually think about this type of sensational journalism in IT, maybe it will have a certain positive effect if it makes more people to take notice and update their tools promptly. Or maybe it gives an additional incentive to software vendors to develop better, more reliable and convenient secure communication solutions.
It is a world of great turmoil and considerable fear amidst incredible human progress. No wonder the RSA keynotes seemed bi-polar - mixing fear one moment, hope and inspiration the next.
RSA opened with a somber act from rapper poet Kevin Olusola to the conference theme: "Now Matters"
“Together we rise, together we fall
Now matters, for one and for all”
Rohit Ghai, President of RSA Security, introduced the conference with the message that - despite the headlines - cybersecurity is getting better, not worse.
Why better? The world reads about breaches, not protection successes. You don't see headlines about the complex, often confidential work performed by many members of RSA’s audience. You don't see how multi-factor authentication, privileged access management, and other layered security measures prevent or mitigate breaches of so many systems.
Ghai continued in a positive vein; we paraphrase him below as he advised the industry to focus on the following “silver linings” of security:
1. End of the silver bullet fantasy
2. Quicksilver law of cyber-defense
3. Magic of sterling teamwork (inside and outside the boat)
End of the Silver Bullet Fantasy
The industry has finally abandoned the idea that ultimate security can be provided by some new silver bullet solution. Like the highly-successful British cycling team in recent Tour de France events, security teams must get the big things right, and work incrementally to improve the little things. Getting the big things right is all about risk management - understanding the company's business context and learning to protect its crown jewels. Only by hardening or denying a small number of key outposts can one finally create defenders' asymmetric advantage over attackers.
Don't ignore the little things. Use threat intelligence and vulnerability analysis to learn where the vulnerabilities are and patch them.
Quicksilver Law of Cyber-Defense
Like basketball, cybersecurity is a high-velocity sport. Players must anticipate the next offensive move and get protection in place first. With new technologies, there is always a learning curve; Ghai called it the “cybersecurity afterthought gap." The only way to counter Murphy’s Law of new technologies is to develop an ability to adopt security measures sooner and better.
Ghai asserted technologies like Intelligent security operations centers (SOCs), automated orchestration, and user behavior analysis (UBA) are working well. We have state of the art visualization in the SOC - “beautiful security” delivered through Slack-like UIs and chatbots. We are getting better at getting to the ball before our opponent.
The Magic of Sterling Teamwork (Inside and Outside the Boat)
Continuing with athletic metaphors, Ghai recalled the US women’s eight rowing team, which had an 11-year winning streak. In the long boat, only the cockswain can see ahead, but the team digs in with trust and coordination. For the crew, teamwork isn’t just needed in the water, but also in other areas such as university programs to recruit a depth of talent.
In cybersecurity, protection must also go beyond the SOC and all the way up to the Board room. It requires contributions from executives, users, and business stakeholders. Regulators must set the tone. Ghai praised GDPR for putting privacy front and center, and The U.S. Cloud Act for balancing tech sector needs with public sector anti-terrorism concerns.
We need to build diversity and inclusiveness into security programs, or we’ll struggle to get security right. We need to build in, not bolt on. We should move security up the software development life cycle (SDLC) and engage developers long before the first pen test of the finished system.
Ghai acknowledged there are major issues. Cybersecurity is impacting financial results of breached companies. Breaches of trust have moved beyond loss of personal information. In the wake of the U.S. 2016 election, purveyors of “fake news” continue to shake citizens’ faith in the media, each other, and democracy itself. Trust in technology is tenuous.
Still, Ghai argues that across the social spectrum cybersecurity is getting better not worse. Cybersecurity provides the protection underlying technological breakthroughs in AI, robotics, and other fields. He highlighted the importance of inclusiveness and noted (to applause from the audience) that twice as many girls, and three times as many ethnic-minority students are enrolled in advanced computer classes.
Ghai closed with: “To protect – it is our great adventure!”
Taking Protection to the Next Level
It was left to Brad Smith, President of Microsoft, to recall the darker moments of 2017 with videos depicting scenes of Wannacry ransomware causing chaos on UK National Hospital Service (NHS) floors, and Notpetya ravaging Ukraine.
Both Wannacry and NotPetya are suspected of being state-sponsored attacks. If so, the world has gone backwards from the days after World War II when states came together to codify civilian’s rights to safety from government attacks. We need a Digital Geneva Convention, Smith said, that stops governments from attacking private sector technology and technology companies. For all this doom and gloom, Smith too had words of encouragement, announcing a new Cybersecurity Tech Accord in which 34 major vendors pledged to uphold principles of civilian protection in cyberspace.
Two Steps Forward, One Step Back
It seems the Cybersecurity Gods delight in irony and don’t appreciate corporate Presidents saying cybersecurity is getting better. News of an apparently minor breach broke toward the end of the conference. Per Paul Ducklin from Sophos: “Well, it looks as though it’s happened again: another insecure app published as part of an RSAC cybersecurity event.” In a late-night tweet, RSA Security acknowledged that 114 first and last names of RSA Conference Mobile App users were improperly accessed. I suppose it is easier for executives to talk about paying attention to the little things and moving security up the SDLC than for the company’s developers to actually do it.
Many feel the Clarifying Overseas Use of Data (CLOUD) Act does not represent the good balance Ghai described, but tramples privacy rights. McAfee CEO Christopher Young’s keynote, which compared the state of cybersecurity to the state of skyjacking in the wide-open skies of the 60s and 70s, seemed (at least loosely) to imply an increasingly centralized and regulated future. If our Internet user experience is to become like U.S. Transport Security Agency (TSA) lines in the airport, many might oppose that, and centralized systems might not be safe or resilient enough. Other paradigms, such as decentralized blockchain-based solutions, were barely mentioned until the Cryptographer’s Panel took the stage.
Conclusion: We Need Not Agree with Everything the RSA keynoters Said to Welcome a Positive Message
Despite RSA’s closing contretemps, a reasonable argument can be made supporting Ghai’s premise that cybersecurity is getting better. It may not seem this way with 2017 logging 45% more breaches than the previous year. However, 2017 also saw vastly increased digital utility and digital transformation in the world. Did the increase in economic value of the Internet exceed the value of cyber-losses? I would have to say “Yes!”
What about the equally reasonable argument that cybersecurity is getting worse because losses are increasing at an unacceptable rate? Losses are going beyond the economic: If many are losing faith in democracy due in part to the cyber-abuses and cyber-conflicts that divide us, could we ultimately face the incalculable loss of democracy itself?
To that also a positive message is the only answer. Per John F. Kennedy: “We have nothing to fear but fear itself.” For the professionals among us: We can go to work each day and make our living, knowing that we stand for safety and privacy. Let that inspire us to work a little harder, do a little better, and do it ethically. We are living the life of making cybersecurity better.
Identity isn't hard when you don't always use it. For example, here in the natural world we are anonymous—literally, nameless—in most of our public life, and this is a handy thing. Think about it: none of us walks down the street wearing a name badge, and it would be strange to do so. A feature of civilization is not needing to know everyone's name, or details about their lives, and to give others information about ourselves on a need-to-know basis.
To be anonymous, however, does not mean to lack distinction. In fact to be human is to be distinctive: designed by nature to look and sound different than other people, so we can tell each other apart. We also add to our distinctions through clothing, jewelry, haircuts, mannerisms and body art. Our souls are also profoundly original in ways that transcend our genetic portfolio. For example, television star Laverne Cox has an identical twin brother. So does transgender activist Nicole Maines. Being distinctive helps relieve us of the need to disclose our names all the time, because in most cases all we need is to be recognizable, or familiar, not identified by name. This too is a grace of civilization.
Our identities are also profoundly personal, and often complex. We start with the names given to us by our parents or our tribe. After that we add abbreviations and nickames, which have conditional uses and conventions. For example, my father was named Allen, but most people called him Al. He and my mother, who was named Eleanor and sometimes went by El, named me David Allen. Mostly they called me Dave. My son Peter's middle name is also Allen, and that's the name he mostly goes by, while family members call him Pete. When I worked in radio, somebody called my on-air persona "Doctor Dave." Then, after I started a business with a one of my listeners whose name was also David (and who didn't like being called Dave), he and our co-workers called me Doc to avoid confusion. As my social network expanded through our growing business, the nickname stuck, and I've been mostly called Doc ever since. (By the way, years after we went into business, I found out David's first name was Paul. David was his middle name. Nobody, even in his family, called him Paul.)
Everything I just described falls under the heading Devon Loffreto was the first to call self-sovereign identity: the kind fundamentally under the control of a single (or sovereign) individual. All the systems by which organizations give us identifiers he calls administrative.
From their start, administrative identity systems have had a hard time coping with the simple fact that identifiers are optional among human beings having human interactions in the natural world, that our default state within those interactions is to be anonymous yet distinctive—and that we especially value anonymity. Proof of how much we value anonymity is the exception to it we call celebrity. Ask any famous person about the cost of their fame and they'll tell you it's anonymity. The bargain is Faustian: while there are many benefits to celebrity, it is also a curse to be recognized by everyone everywhere, and known by name.
The world's administrative systems have little use for anonymity. After all, they require identifiers for people, so they can know who they are serving, arresting, or sending messages. Knowing people by name has many advantages for administrative systems, but also presents problems in the networked world for both those systems and human beings. Requiring "an ID" for every person puts operational and cognitive overhead on both sides. In the natural world, a boundless variety of business interactions only require that the business know who they encounter is human, trustworthy, and worth the time and effort.
In the networked world, however, we are still stuck with systems comprised of “identity providers” and “relying parties” that reduce individuals to mere “users” burdened with logins and passwords—or convenienced by the Faustian bargain of "federated" identities that let them login with Facebook, Linkedin or Twitter. In these systems, who we are as individuals is secondary to the needs of identity providers and relying parties and the transactions their systems perform, most of which eliminate anonymity. This is dehumanizing. Even the GDPR, which was created to cause respect for personal privacy, and to protect it, reduces us in compliance considerations to mere “data subjects”: a label that is barely less demeaning than “user” and “consumer.”
While these systems are digital, their legacy designs are industrial: top-down and one-to-many. They also grew into their current forms within the architecture of the client-server Web, rather than atop the peer-to-peer (aka end-to-end) Internet beneath the Web (and everything else). This made sense in the early days of dial-up and asymmetrical provisioning of bandwidth, but is a stale legacy in a time when everyone has ample bandwidth in both directions, most commonly on a mobile device that works as an extension of one's body and mind.
In today's networked world, we need approaches to identity that start with human agency, and are modeled on the way each of us operates in the natural world. We should be able to disclose and express our distinctions, choices, requirements and existing relationships with ease—and with anonymity as the defaulted social state until we decide otherwise.
These are the base requirements addressed by many of today's pioneering self-sovereign identity systems and approaches. Here's the key thing to bear in mind: while self-sovereign identity needs to work with existing administrative identity systems, self-sovereign identity cannot be fully understood or explained in terms of those systems—any more than personal computing can be explained in terms of a mainframe, or the distributed Internet can be explained in terms of a centralized LAN.
When each of us has full control of our naturally self-sovereign identity in the networked world, there is no limit to what we can do—while the limits of administrative systems are painfully apparent. (Example: logins and passwords, which everyone hates.)
This doesn't mean, by the way, that we should throw out the great work that has been done with administrative systems, especially those that have obeyed Kim Cameron's Seven Laws of Identity, which he first wrote in 2004. Here they are:
1. User control and consent
2. Minimum disclosure for a constrained use
3. Justifiable parties
4. Directed identity
5. Pluralism of operators and technologies
6. Human integration
7. Persistent experience across contexts
Today those laws apply to both self-sovereign and administrative identity, and remain an especially helpful guide if we change the first word in that list from “User” to “Personal.”
The time has come to humanize identity in the networked world by making it as personal as it has been all along in the natural one. We can also make progress a lot faster if veterans of administrative systems try to understand self-sovereign approaches from the perspective of how they, as naturally sovereign human beings, choose to be known.
The Equifax data breach saga continues to unfold. In late 2017, the company admitted it had suffered significant data loss starting in March of last year. There were likely multiple data theft events over a number of months. At some point in May, they notified a small group of customers but kept mostly quiet. Months later the story went public, after Equifax contacted government officials at the US federal and state level. The numbers and locations of consumers affected by the breach keeps growing. As of March 1, 2018, Equifax is reported to have lost control of personally identifiable information on roughly 147 million consumers. Though most of the victims are in the US, Equifax had and lost data on consumers from Argentina to the UK.
Perpetrators made off with data such as names, addresses, Social Security numbers, and in some cases, driver’s license numbers, credit card numbers, and credit dispute files. Much of this is considered highly sensitive PII.
The breach and its effects on consumers is only part of the story. Equifax faces 240 class action lawsuits and legal action from every US state. However, the US Consumer Financial Protection Bureau is not investigating, has issued no subpoenas, and has essentially “put the brakes” on any punitive actions. The US Federal Trade Commission (FTC) can investigate, but its ability to levy fines is limited. On March 14, 2018, the US Securities and Exchange Commission (SEC) brought insider trading charges against one of Equifax’ executives, who exercised his share options and then sold before news of the breach was made public.
Given that Equifax is still profiting, and the stock price seems to have suffered no lasting effects (some financial analysts are predicting the stock price will reach pre-breach levels in a few months), fines are one of the few means of incentivizing good cybersecurity and privacy practices. Aiming for regulatory compliance is considered by most in the field to be the bare minimum that enterprises should strive for with regard to security. A failure to strictly enforce consumer data protection laws, as in the Equifax case so far, may set a precedent, and may allow other custodians of consumers’ personal data to believe that they won’t be prosecuted if they cut corners on cybersecurity and privacy. Weak security and increasing fraud are not good for business in general.
At the end of May 2018, the General Data Protection Regulation (GDPR) comes into effect in the EU. GDPR requires 72-hour breach notification and gives officials the ability to fine companies which fail to protect EU person data up to 4% of global revenue (or €20M) per instance. If an Equifax-like data breach happens in the EU after GDPR takes hold, the results will likely be very different.
Regulators in all jurisdictions must enforce the rules on the books for the good of consumers.
Traditional endpoint and infrastructure security approaches are tackling changes to OS, application and communication by monitoring these through dedicated solutions installed as agents onto the actual system. Often these solutions search for specific violations and act upon predefined white listed applications / processes or blacklisted identified threats.
Due to their architecture, virtualization platforms and cloud infrastructures have completely different access to security-relevant information. When intelligently executed, real-time data and current threats can be correlated. But much more is possible from the central and unique perspective these virtualized architectures allow. Observing the behavior of components in the software-defined network, comparing this with their expected behavior and identifying unexpected deviations allows the detection and treatment of previously unknown threats up to zero-day attacks.
Manufacturers such as Citrix and VMware are working at full speed to provide high-performance, integrated security infrastructures as part of their platform. These may be delivered, for example, not only as a component of hypervisor, but also as a component of a hybrid security architecture between cloud, virtualization and bare metal.
By going beyond traditional “known good” and “known bad” approaches through black-listing and whitelisting, such solutions provide an intelligent approach for infrastructure security. The approach of capturing the actual runtime behavior of existing software systems to learn expected and appropriate behavior while applying algorithmic control and monitoring in later phases has the potential to be able to cover a vast number of systems, including homegrown and enterprise-critical systems. Earlier this year, KuppingerCole published an Executive View research document on VMware AppDefense as a representative of this innovative security approach. And just this week VMware announced the availability of AppDefense in EMEA as well as extended capabilities to protect containerized workloads.
If legal laypersons (as I am) read legal texts and regulations, they often miss clear and obligatory guidelines on how to implement them in practice. This is not least due to the fact that laws are generally designed to last and are not directly geared to concrete measures. This type of texts and provisions regularly contain references to the respective "state of the art".
For example, it is obvious that detailed requirements on how companies should implement the protection of the privacy of customers and employees cannot necessarily be found in the EU General Data Protection Regulation (GDPR). The appropriate implementation of such requirements is a considerable challenge and offers substantial scope for interpretation, not least when having to decide between "commercially sensible" and "necessary".
While many organizations currently focus on the implementation of the GDPR, the BAFIN (the German Federal Financial Supervisory Authority "Bundesanstalt für Finanzdienstleistungsaufsicht), published a revised version of its "Minimum requirements for risk management"("Mindestanforderungen an das Risikomanagement", MaRisk). Often unknown outside of the financial sector, this regulatory document provides a core framework for the overall implementation of financial business in Germany and subsequently worldwide. MaRisk concretize § 25a Paragraph 1 of the German Banking Act („Kreditwirtschaftsgesetz“, KWG) and are therefore its legally binding interpretation.
The new version of MaRisk has been extended to include a requirements document that deals with its concrete implementation in banking IT, so to speak as a concretisation of MaRisk itself. This gives financial institutions clear and binding guidelines that become valid without a long-term implementation period. This document, entitled "Supervisory Requirements for IT in Financial Institutions" covers a large number of important topics in the implementation of measures to meet the IT security requirements for banks.
It does this by describing (and calling for) an appropriate technical and organizational design of IT systems for financial services. Particular attention has to be paid to information security requirements. It aims at improving IT service continuity management and information risk management and defines how new media should be handled appropriately. Beyond pure technology, a variety of measures are designed to create an enterprise risk culture and to increase employee awareness for IT security and risk management. And it includes specific requirements for modernizing and optimizing the bank's own IT infrastructure, but gives clear advice also with regard to the aspect of outsourcing IT (think: cloud).
Financial institutions must define and implement an information security organization, in particular by appointing an information security officer. Adequate resource planning to support the defined information security must ensure that this agreed security level can actually be achieved.
For national and international banks, meeting these requirements is a essential challenge, in particular due to their immediate applicability. But should you be interested in these requirements if you are not active in Germany or maybe you are not a bank at all?
From my point of view: Yes! Because it is not easy to find such clear and practice-oriented guidelines for an appropriate handling of IT security within the framework of regulatory requirements. And it is to be expected that similar requirements will become increasingly relevant in other regions and sectors in the future.
KuppingerCole will continue to monitor this topic in the future and integrate the criteria of the BAIT as a relevant module for requirements definitions in the area of enterprise IT security.
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.
AI for the Future of your Business: Effective, Safe, Secure & Ethical Everything we admire, love, need to survive, and that brings us further in creating a better future with a human face is and will be a result of intelligence. Synthesizing and amplifying our human intelligence have therefore the potential of leading us into a new era of prosperity like we have not seen before, if we succeed keeping AI Safe, Secure and Ethical. Since the very beginning of industrialization, and even before, we have been striving at structuring our work in a way that it becomes accessible for [...]