A security architect’s POV on a mature data-centric security program, Part 2
In part one of this series, we explored the challenges associated with accessing and searching long-term retained database activity logs, and identifying sensitive customer data to comply with stricter compliance regulations. In this post, you’ll see through a security architect’s eyes the challenges of managing organizational leadership through the transition from compliance-centric to data-centric security.
Managing executive teams through the transition from compliance to database security
The ongoing addition of more on-premise and cloud-native data sources has grown the cyberattack surface. Security architects face increased threat volumes and the continual elevation of cyber security as a business issue. Too often, board rooms and executive suites do not see the problem. A recent NOMINET survey* revealed only 60% of CISOs believe that their CEO/President agrees a breach is inevitable and nearly one in five believe their board members are indifferent to the security team or see them as an inconvenience. Further, the survey findings show that 30% of CISOs say their executive team had no security expertise and 65% claim lack of senior leadership buy-in is a barrier to addressing security issues. These points all underscore a critical disconnect between those responsible for security and the rest of the organizational leadership team.
This disconnect is even more pronounced in cases of migrating workloads to cloud-native architectures. One security architect we interviewed commented, “Prepare for more data security breaches in the cloud. Leadership groups have placed a great deal of pressure on people to jump into the cloud before a plan to secure the data is ready. Unfortunately, members of the leadership team often lack critical technical insight. Most have basic technical skills sets but they spend most of their time managing the work, not doing it. They are not off in dark rooms digging through data, but they are the ones making the major strategic technology decisions.”
In some instances, companies have chosen specific database systems based on a single word of mouth recommendation. All organizations have gone or will soon go to the cloud, but often the people giving the orders don’t know if there are enforceable security policies in place to mitigate the risk of data breaches. They don’t know if their security teams can protect their data in the cloud-native architectures they have chosen. Still, executive team members are ordering workloads to be migrated to the cloud now.
This practice puts all companies at risk when moving workloads to the cloud. Not because the cloud-native architectures are not secure. In fact, they are often more secure than on-premise environments because they have been purpose-built to be secure. The problem is the executives often don’t know for sure that their security teams have visibility into the cloud-native architectures they are using so they can extend security policies to them.
Another security architect commented, “Leadership at most companies really don’t understand what data security and database security mean. They think ‘I have a network team, they’ve set up firewalls up there, and I am requiring tough passwords.’ That’s the extent of their thinking about data and database security. They need to understand in database security, things are not always as they outwardly appear. For example, about a year ago, one company I work with decided to outsource a project to a vendor. The vendor gave a list of information they would need to complete the project. The company thought there might be sensitive data in what the vendor was asking for, so as the security architect I spent four weeks going through the data they wanted. As we suspected, there was sensitive data in the databases the vendor requested. The leadership team said, ‘It’s OK, we’ll be fine.’ Except that was probably not true. They really had no idea what personal data is. Names, addresses, or driver’s license numbers as separate fields are not necessarily personal data. But a name plus an address plus a driver’s license number together most certainly is. In the end, the company did not choose to work with the vendor because it was not satisfied with the vendor’s security system. Leadership lets the market drive these things, which is fine, but too often it does not happen in a secure manner.”
As we mentioned, most cloud-based services vendors do a good job securing the systems in which your data is stored. This is only one aspect of database security in the cloud, however. At a recent virtual conference session on database security considerations when migrating workloads to the cloud, an attendee asked the question, “What can I do to ensure a cloud vendor can secure my company’s sensitive data?” And the speaker replied, “it’s not the cloud vendor’s responsibility to ensure your security controls are being extended to cloud environments, it’s yours.”
As is the case with any service provider, the cloud service vendor will do its best to ensure that there are no flaws in their overall systems to allow a breach, but your organization’s data within the cloud instance is your responsibility. Think of it as a storage unit. The unit provider furnishes the storage locker itself and will ensure the locker is up to standards, sometimes even providing some basic perimeter security, but you are responsible for buying your own lock and ensuring the security of your unit. If you decide not to lock it, don’t be surprised if people access your locker and steal your property. It’s a common and dangerous misconception that the cloud vendor has visibility and oversight over how your sensitive data is being protected. It’s not the cloud vendor’s responsibility to provide it. They provided you with the service, but security is on you.
The security architect continues, “You need to ask the service provider if they can locate sensitive data and ensure it’s not being copied or otherwise exposed. Does the provider enforce your organization’s security controls like user privileges and entitlements? Do they test to confirm the service is configured properly? Do they do their own audits for regulations like GDPR or the Insurance Data Security Model Law? These are the things you need to think about because probably nobody else is.”
*The security architects’ quotes in this piece are not from the NOMINET Survey and are in no way affiliated with or related to it.
Next time: Take the time to explain database security to your analytics teams in a way they can understand.
The post A security architect’s POV on a mature data-centric security program, Part 2 appeared first on Blog.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Bruce Lynch. Read the original post at: https://www.imperva.com/blog/a-security-architects-pov-on-a-mature-data-centric-security-program-part-2/
