This session from ERP Suites AI Week, led by Brian Connor and Sean Meade, explores critical aspects of protecting sensitive data in AI environments on Oracle Cloud Infrastructure (OCI). The discussion covers default encryption mechanisms, customer responsibilities for data classification, compliance, and retention, as well as essential tools like CloudGuard, security zones, and vulnerability scanning. Additional focus is placed on secure system interconnections, denial of service (DoS) protection, boundary safeguards, malicious code defenses, and configuration best practices. Together, these strategies ensure AI deployments remain secure, compliant, and resilient against evolving threats.
Table of Contents
- Session Scope and Objectives
-
Denial of Service, Boundary Protection, Malicious Code, and Configuration Wrap-Up
Transcript
Welcome and Introductions
Good afternoon everyone and welcome to day three of ERP Suite AI week. We are very glad to have you with us today. And if you're hearing me that means my audio is actually working for you today as opposed to the previous two sessions that we had. So uh you don't just have to listen to Sean, you actually get uh you have to listen to me as well. So that being said, today's session we saved the best for the last day of AI week. the uh the the topic that keeps uh everybody pinned to their to their seats is uh protecting sensitive data uh encryption and infrastructure security for artificial intelligence. My name is Brian Connor. I am the director of JD Edwards security for ERP suites. I've been here just over three years. Uh very happy to be joining you today for AI week. And co-hosting today's session uh is Shawn Meade. Sean, I'll go ahead and let you introduce yourself. Thanks, sir. Uh, my name is Sean Meade. I'm the information security officer for ERP Suites. Um, I've been here for a few years and uh have enjoyed it immensely. Uh, I am I have a strong security background of course and and some uh and by the way, I always like throwing this out there. I'm a member of something called Infra Guard. If you would like some information on that uh for yourself or or some colleagues, that's infragard.org. I infr A d.org. It's a uh collaboration between the FBI and the private sector. So check that out sometime. It's kind of neat. But more importantly, uh as we get ready to move forward with this uh today, as Brian stated, we are talking about protecting sensitive data.
Session Scope and Objectives
So in this in this presentation today, this part of this, we're going to basically be covering two different domains. Uh their data encryption and infrastructure protection. There going to be some overlaps between these different pieces. Uh some of the same tools will be mentioned in different areas or different objectives during this, but that's actually a very positive thing is we always like to see security kind of over overlapping a little bit. keeps us from having gaps in between. So what we want to do today is uh our goal is to describe the process and the tools that make uh make it possible for us to achieve any and all of these uh different objectives. So also by the way when we start talking about the data encryption uh we're going to be talking about not only what it is and how to engage it but also responsibilities for your vendor uh and for you as the customer uh the different responsibilities in that matrix.
Data Encryption in OCI (Defaults and Mechanisms)
And with that we're going to get into data encryption now. Uh in OCI the nice thing is that data encryption is enabled by default. This is not something that you have to remember to go in and turn on. Uh and as a matter of fact, you can't turn it off. So, it's there. It's always on and it's always protecting your information.
So, what does it do? So, it protects uh and encrypts your data in transit. So, when it's going from point A to point B, whether it's an API call uh or anything else, uh it's encrypted. And encryption at rest. This is critical because in any attempt from uh a threat actor to come in and grab your data, if it's already encrypted, it really doesn't matter because they can't read it. It also keeps them from re-encrypting it to keep you from being able to use it. So encryption in transit and encryption at rest.
Everything—all communication between clients and OCI services—will utilize right now TLS 1.2 or higher. As additional standards are released, OCI tests and validates those and they will begin using the higher-level standard as soon as they're able to. So, you don't have to worry about that upgrade happening. They do it automatically for you. So, right now it's TLS 1.2 or higher. Certificates are always issued from a reputable uh certificate authority.
Data stored within the object storage databases and block storage is encrypted and again by default you don't have to remember to turn this on. It's always encrypted by default. This is a huge advantage that you don't have to worry about a misconfiguration or somebody unchecking a box and unencrypting or making it available in any way, shape or form.
Uh you have usage of either Oracle managed keys or customer managed keys through the key management service in a key vault in the OCI tenancy.
And then one of the tools you want to make sure you use is an annual rotation of your encryption keys is highly recommended. So again you can use the Oracle keys or you can use your customer managed keys. I think the recommendation from us as well as from Oracle is always to use a customer managed key. Even with that, you want to make sure that that is rotated on an annual basis.
Customer Responsibilities for Data Protection
Now we move on to the customer responsibility along the lines of data encryption. So I I think all of these are very important for us to about which we should have an awareness.
So data classification—no vendor can classify your data for you. Uh this this is something that should be done by any customer. You need you know what your important data is, what you need to protect the most. Maybe you have trade secrets uh not just a patent or something but a trade secret which once it's out it's out. That would be unknown to your vendor. And data classification is one of the first and most important things you can do for determining how critical data is in your environment.
So identification—and as we look down at the tools—identification and tagging of sensitive and regulated data, that's something the customer uh would be where that responsibility would be because only you know your data that well and only you know all of your uh compliance issues that you have.
So for example, let's go on to the compliance management. Now maybe you have to adhere to GDPR, maybe you have to go with HIPPA, maybe you have PCI, that is not necessarily what other customers are going to have of your vendor. So whether your vendor is uh ERP, whether it's AWS, Azure, OCI, any of the 20 million out there, they are not going to know what the regula—what the regulations are that you have to uh make sure you're following along that path. So compliance management is something that is a customer responsibility.
Another area that's kind of uh not thought of in a lot of cases: data retention. So not all customers have a data retention policy because they may not have data retention compliance about which they're concerned. So when we're looking at this again, the customer needs to define and thereby manage the long-term storage policies. You can relay that to your vendor. You can tell your vendor, I need this deleted in this regular fashion. I don't want this kept more than two years. Whatever your classification and your definitions are for your compliance to meet your compliance needs, that's how you should define the data retention.
And of course, that leads straight into the audits and reviews because your auditors—if you need to be GDPR, HIPPA, PCI, whatever it may be, high trust—you're going to need to have evidence for any of these. So, there needs to be a guidance document that the customer has on data governance. Not only overall these definitions that we brought forward but also the responsibility matrix uh that exists with those. So be aware uh of where those lines are in the responsibility matrices when it comes to these responsibilities so that no one gets caught off guard.
Absolutely. Uh interesting—I had a client uh several years ago talking about the data classification and privacy. Their uh their bomber bill of materials in JD Edwards was so sensitive that not even the people that were ordering were allowed to know the specific uh ingredients that they were ordering for what they were manufacturing. I'm not going to say what industry it was, but even you know they had to mask some of that information because it was so uh crucial to what they did that they were you know exceptionally uh cognizant of the sensitivity of that information. So whether it's an on-prem or in the cloud, absolutely agree with Sean. The the data classification is something that a customer really absolutely has to own.
Yes sir.
Another thing that the uh customer owns is your security assessment. So having a regular review of your security posture for your cloud environment as well—since we're in a JDE space—for your JD Edwards environment. Being able to assess your security and compliance posture and understand where you are uh is crucial to ensure that what you deployed as secure is still secure a year later, two years, five years down the road.
Security Assessment and Monitoring Tools
So there's three main tools that we use in OCI for this. We have the OCI audits which tracks all of your nonhuman activity in this instance. So we're looking for any API activity. Is your API making any unexpected calls? Is it only doing things that you expect or is it going elsewhere with that? So auditing this type of activity is key—and not just auditing it but then going out and reading those audit logs and taking a look and making sure that you're comfortable with everything that's happening in your system.
The next one—and this is going to come up in a few of the objectives here—is CloudGuard. So CloudGuard is your sentry. It's looking at, it's enforcing, and you can automate the responses to any activity that could be considered a threat. So if there's anything going on in your system that you don't want to have going on, CloudGuard is a great tool where you can define not just what it's looking for, but you can automate a response. So in real time, rather than having to have somebody come back and look at a log and then determine what to do about it, it's doing it real time. You want to prevent that from happening in the first place.
So the last thing is the security zone. These—this is the foundation which defines what actions can be taken by the predefined roles and policies that you've set up in your identity and access management which, if you didn’t attend our session from earlier in the week, we have the recording out there. So I would recommend you go out and find that recording and listen to that. We've got some great information there. This also helps contain activity within the instance and it enforces your secure configuration choices. So what you've defined upfront, it makes sure that you aren't going outside of those boundaries further down the road.
So maybe you have somebody new come in to manage your cloud instance and they aren’t quite sure what's allowed or what's not allowed. Well, you've defined those guard rails in your security zones to make sure that nobody's doing anything that you are unaware of.
Vulnerability Scanning and Container Security
Now that we've talked about some of these other tools, some of our assessments, where our responsibilities are with data encryption, things of that nature, another thing that we want to make sure we are closely monitoring would be vulnerabilities.
OCI has a good choice right out of the box that we can use for this. So let's go ahead and look at this in our process. Vulnerability scanning ensures that the AI infrastructure—all of these different pieces—is secure from known threats. Now I personally want to make sure we stress from known threats. That's what vulnerability scanning is. This is not necessarily day zero, but this makes sure that we don't have something that's out there that has not been patched for the past two months and now we just had a vulnerability exploit that has come out that is attacking the very thing that we have not yet patched.
These scans also validate in OCI that AI models and associated APIs are not susceptible to exploitation. So again, we're coming back to the same thing. We need to make sure that we are scanning for vulnerabilities so that an exploit on a particular vulnerability does not take us out.
Quite honestly, the tools that are available for this—well, OCI has a built-in vulnerability scanning service. It scans our compute instances and container images. So I think that's important for us to realize—it's not just the compute but also the container images for any of the known vulnerabilities.
And this of course—you know somewhere we managed to get AI, those two letters, in here. Ensuring the AI infrastructure is secure and that is what we're trying to do. I'm saying that half jokingly, but AI is where our focus is, and some of these things that already existed are critical in the ongoing movement and use of AI in all of our different areas.
Another tool that is in OCI already is container registry. It integrates with vulnerability scanning and it winds up securing containerized AI workloads. So these availabilities—and there are other things available in the OCI cloud marketplace—these things are already, because they're available there, that means they will work in the OCI space. That means that we can use that right out of the box pretty much.
And it also—you know—these allow us to have things like compute instances available from that same place, the marketplace, that are already CIS (Center for Internet Security) compliant. So these are the types of things that are available—not only vulnerability scanning, but the tools that are available to help us right out of the gate make sure that we don't have exploitable machines, systems, VMs, whatever term you want to use, already out there from the start.
System Interconnections and Secure Networking
Good, right? All right. Next up is system interconnections. If you all are JD Edwards users, you know how chatty JD Edwards is. Communication between systems is absolutely key. So having a predefined secure and scalable network infrastructure with your Oracle VCN—it’s already CIS compliant as Sean mentioned, Center for Internet Security—gets you off on the right foot. Make sure that everything is ready to go out of the box. You've got public zones, you've got private zones, using CloudGuard security zones to make sure that everything is working as designed.
The IAM configuration that is delivered by ERP Suites with our landing zone implementation for OCI provides foundational security to ensure all of the communication requirements have already been discovered, documented and delivered out of the box. So once we implement a landing zone for AI in OCI, you know that everything is already there and it's going to work just out of the box.
The FastConnect provides a secure—and more importantly a private—connection to on-premise systems or third-party data sources. So again when you're talking with JDE with AI or with anything in OCI, you may be on-prem for some things and in the cloud for some things or using multi-cloud. Having a protocol or a service available from Oracle, the FastConnect, makes sure that it is both secure and private.
And the last bit is the Service Gateway. So again, when you're looking to access OCI services, you don't necessarily want to traverse the public internet. So you're using the Service Gateway to have that private point-to-point communication that's not in a public domain.
And Brian, you and I know from just all the security we've had to do, there is no better way to recognize counterfeit than to know what the real thing is. I remember being—I was employed at a bank once as a teller a long time ago—and one of the neatest things I thought they had done was they came out and they said, "Well, here's a counterfeit. Here's another counterfeit. Can you recognize these?" And then in the end, the head of security for that wound up telling us, "Look, the best way that you can recognize a counterfeit is by knowing everything about the real thing."
And I bring that up because I think that fits here. If we have these system interconnections set up the way we want to, then we are doing it based on what we know should be. And if something tries to go off the rails, that helps us to know. Sorry—that just came to my mind as far as that recognizing the counterfeit thing when we were hitting this.
Absolutely.
You bet.
Denial of Service, Boundary Protection, Malicious Code, and Configuration Wrap-Up
And as we go on to denial of service protection, I want to make sure before we even go into the process and the tools that we really do consider how much of a vulnerability this can be. If someone is targeting you—I don't know, your company's in some area that is currently being attacked for whatever reason, they've just been on the news for something—whatever it could be, then you know that there are going to be cyber attacks that could possibly come your way. And quite honestly, one of the first things that I've seen attempted in many cases instead of going through all the trouble of piercing the veil as it were is let's just try and stop the communications from the start. So denial of service protection is very important especially in this day and age.
So the process on this: when we look at AI services hosted on OCI, as I've just said, they could be targets disrupting availability and performance. That is the whole reason for DOS attacks: they're just simply wanting to make it so busy that your website, your access, goes down. The OCI DOS protection ensures that these AI services remain operational. So with these different tools—and I'm going to mention two of them here.
OCI Web Application Firewall. I'm sure that many of you have seen the abbreviation WAF before and have heard that being used in cyber security. This protects AI APIs and applications from common web-based attacks, including DOS. Another tool is the one that makes the most sense in its name: OCI DOS protection provides always-on DOS mitigation. So there are a number of tools included in OCI's cloud deployment.
Now one of the things that should be viewed as an important area is to segregate the responsibility for these various tools. Make sure that there's no single account that has complete control over everything. Again, remember denial of service—we think of DOS attacks specifically on web servers and things of that nature, but they can also occur by having an entry point of a server—or I’m sorry, an account—that basically has access to absolutely everything and then there's one target and once that target is broken, it's kind of over with. The web application firewall, by the way, is included with OCI. There are options for this in the marketplace if you're wanting to use other things other than what they have, but again, we're using this as the primary example for helping with denial of service protection.
And again, like we mentioned at the beginning, even if they're not trying to steal the data, they just want to hurt you. One of the ways to hurt you is to make it so that your services go down, especially depending on your industry.
Absolutely. Reputational damage doesn't just come from loss of data or a breach. It can come from unavailability of your services, especially on a launch day for a new product or a new service and all of a sudden customers can't get to it. So, DDoS is definitely a tool that threat actors will use to get what they want out of you.
So, next up is our boundary protection. And this is somewhat of a misnomer because do you ever really have a defined boundary when you're in a cloud environment? It used to be pretty simple and straightforward when—back in the good old days—everything was on prem and you had your data center and you had everything contained within a known footprint. In these days, when you've got a lot of AI services in a lot of different areas, not just in JD Edwards, boundary is flexible and it's a little bit fluid.
When it comes to OCI AI, for example, we're looking at a lot of external interfaces—so APIs that require very strong protection to prevent unauthorized access. So we've looked at other tools where we're monitoring and logging that type of information. But we're also looking at boundary protection mechanisms. As Sean said in the last slide, again, we're looking at the Web Application Firewall or the WAF to safeguard the interfaces and the data pipelines. We want to make sure that you know what communication is going on.
So part of this again is the network security groups. It gives you this granular level access to resources such as compute instances running AI models. You have the secure gateways for communicating with the AI instances. And it comes back down also to your IAM which is identity and access management—what your roles and policies and authorizations are for who can do what. You don't want a single account that has ownership and admin access to absolutely everything within your system.
When we look at things as members of the security team, when we look at our OCI instance, we don't have access to create buckets, we don't have access to create VCNs or do anything with them. We have access to what we need to do as part of the security team and that's it. So those security lists, network-level boundary protections for subnets in the VCN, and again the WAF, it gives you another layer of protection for those API calls and for your endpoints. So when you have all of these done along with segregated identity access management controls, you've got a great start to begin your AI journey in OCI.
Now another thing from which we need to be protected is malicious code. So I think we can be aware that AI is still software. So by that definition, it can be at risk of malicious inputs, injections. What we want to do to shield ourselves is use OCI security tools, which we can do to protect us against that malicious code that could corrupt the AI pipeline because that would be very detrimental because of the way AI works in the first place.
Some tools along this path: the code repository, OCI code repository and DevOps services. This of course lets us have secure code repositories. The OCI Bastion—this is kind of like a ball pit. You’ve seen these with the fence all around them. You can play in there, you can bounce around, but the real world's not impacting you and you're not impacting the real world. So that keeps it protected in both directions for testing. And then CloudGuard—this identifies anomalies and suspicious activities. And these are tools that are available to us.
All right, I know we're getting close to the end here. So our last item we want to cover is configuration settings. This is kind of a wrap-up for everything else that we've talked about. So your AI systems rely on secure optimized configurations for your compute, your storage, your network, virtual cloud network. Misconfigured settings can expose your data.
OCI has a lot of best practices and automated compliance checks. So configuration compliance services, CloudGuard, Resource Manager, looking at making sure that you're controlling your budgets, controlling your access, and making sure that everything is secure. So I wanted to wrap up a little quicker than normal on this particular slide because I know we've only got about three minutes left and I wanted to give time for any questions that anyone may have.
And Brian, my apology to everyone for not having a little more time at the end. I kind of got on a little bit of a soapbox on that denial of service, but I think that people overlook that a lot. So, sorry.
No worries. I think there's a lot of good information and it is tough to fit it all into 30 minutes.
Video Strategist at ERP Suites