Archive for application security

Deploy an Auto-Scaled BIG-IP VE WAF in AWS

Posted in security, f5, big-ip, application security, cloud, privacy, waf, aws by psilva on August 29th, 2017

Today let’s look at how to create and deploy an auto-scaled BIG-IP Virtual Edition Web Application Firewall by using a Cloud Formation Template (CFT) in AWS. CFTs are simply a quick way to spin up solutions that otherwise, you may have to create manually. The idea behind this CFT is it is going to create BIG-IP VE instances for you. These instances function as a firewall in front of your application. Depending on the limits you specify, when more traffic is going to your application, new instances will launch…and when there is less traffic, instances will terminate.

awaf1.jpg

This solution has a few prerequisites:

  • A Virtual Private Cloud (VPC) with at least two subnets, each in its own availability zone
  • An AWS Elastic Load Balancer (ELB), which serves traffic to the BIG-IP VE instances
  • An SSH key pair which you need to access the instances.

I have these already created, so we’ll proceed to deploying the template.

You have two choices on how you want to deploy. You can go to the AWS Marketplace and search ‘f5 waf’ or you can go to the F5 Networks GitHub site. GitHub usually has the latest and greatest, so we’ll use that.

Click on the f5-aws-cloudformation spot.

awaf2.jpg

And then click Supported.

awaf3.jpg

And then click solutions/autoscale.

awaf4.jpg

Then waf.

awaf5.jpg

We scroll down a little bit and click Launch Stack.

awaf6.jpg

We click Next at the Select Template screen and fill out the template.

awaf7.jpg

When you get to the template, the Deployment Name will be appended to all the instances so you can tell which ones are yours. Since we already set up a VPC with two subnets in two zones (not regions), we’ll select those in the VPC ID field. The Restricted Source Address is available if you only want to allow specific IP addresses to your BIG-IP VE instances.

awaf8.jpg

Next is the AWS Elastic Load Balancer name, then choose your SSH key – which is needed to connect to the instances. And we’ll leave the defaults for the rest.

awaf9.jpg

Then you’ll get to the Auto Scaling Configuration section which is where you’ll determine when to create the new WAF instances. You’ll want to configure the Scale Up & Scale Down Bytes Threshold which will, obviously, determine when one gets launched/added and when it is removed.

awaf9a.jpg

Under WAF Virtual Service Configuration, is where you’ll enter the application’s Service Port and DNS. In addition, if you wanted to automatically add application servers to the pool to have traffic will go to those without having to manually configure the BIG-IP, you can also add the Application Pool Tag Values which works great. Next choose your WAF Policy Level (low, medium, high) and click Next and Next.

awaf9b.jpg

Also, click the check box with indicates that you have the appropriate credentials to set some IAM roles and create a S3 Bucket. Click Create and the CFT will start creating resources.

awaf9c.jpg

This process can take about 15 minutes to complete and when it is done, you’ll get the CREATE_COMPLETE on your dashboard. The resources might be available right away but it is recommended to wait at least 30 minutes before digging into things.

awaf9d.jpg

To see what the CFT created and confirm completion, go to: Services>EC2>Auto Scaling Groups. You can see that there is a BIG-IP VE instance created and added to the group. Also, be aware that the default for Scaling Policies is to wait 40 minutes to launch a new instance. You may want to adjust that to your preference. However, to be clear, AWS is always monitoring the traffic and want to know if you are exceeding the limits you’ve set. The Scaling Policies setting simply means that after one instance is launched – you hit the limit and one is up – AWS should wait 40 minutes (or whatever your value is) to launch another. It’ll keep going until you’ve hit the max number of instances specified. We put three.

awaf9e.jpg

While in Services>EC2, you can also inspect the ELB and see that the BIG-IP VE instance is there and in service. Traffic is going through the Load Balancer and then to the BIG-IP VE, then to the application server.

awaf9f.jpg

Lastly, let’s look at the list of instances in Services>EC2>Instances and the instances are there and ready to go!

awaf9g.jpg

And then when there is too much traffic, another is added. Since the limit was exceeded, AWS has launched new instances, up to three.

awaf9h.jpg

And when the traffic falls, the instance shuts down.

awaf9i.jpg

That’s it! Easily scale your BIG-IP application security on AWS. Thanks to our TechPubs group and watch the video demo here.

ps

 




Lightboard Lessons: BIG-IP ASM Layered Policies

Posted in security, f5, big-ip, application security, asm, lightboard, devcentral, waf, policy by psilva on August 23rd, 2017

In this Lightboard Lesson, I light up some use cases for BIG-IP ASM Layered Policies available in BIG-IP v13.

With Parent and Child policies, you can:

  • Impose mandatory policy elements on multiple policies;
  • Create multiple policies with baseline protection settings; and
  • Rapidly push changes to multiple policies.

ps

Watch Now:



Lightboard Lessons: Attack Mitigation with F5 Silverline

Posted in security, f5, big-ip, application security, cloud, silva, video, lightboard, devcentral by psilva on July 19th, 2017

In this Lightboard Lesson, I describe how F5 Silverline Cloud-based Platform can help mitigate DDoS and other application attacks both on-prem and in the cloud with the Hybrid Signaling iApp. Learn how both on-premises and the cloud can work together to create a composite defense against attacks.

ps

 

 

Watch Now:



Security Trends in 2016: Securing the Internet of Things

Posted in security, big-ip, application security, devcentral, iot, sensors by psilva on February 7th, 2017

mirai-trojan.png

Whenever you connect anything to the internet, there is risk involved. Just ask the millions of IoT zombies infected with Mirai. Sure, there have been various stories over the years about hacking thermostats, refrigerators, cameras, pacemakers, insulin pumps and other medical devices along with cars, homes and hotel rooms…but Mirai took it to a new level.

And it’s not the only IoT botnet out there nor are these nasty botnets going away anytime soon. There’s a gold mine of unprotected devices out there waiting to either have their/your info stolen or be used to flood another website with traffic.

This is bound to compound in the years to come.

A recent Ponemon Institute report noted that an incredible 80% of IoT applications are not tested for vulnerabilities. Let’s try that again – only 20% of the IoT applications that we use daily are tested for vulnerabilities. There’s probably no indication or guarantee that the one you are using now has been tested.

R025_Fig1_1.jpg

Clearly a trend we saw in 2016, and seems to continue into 2017, is that people are focusing too much on the ‘things’ themselves and the coolness factor rather than the fact that anytime you connect something to the internet, you are potentially exposing yourself to thieves. There has been such a rush to get products to market and make some money off a new trend yet these same companies ignore or simply do not understand the potential security threats. This somewhat mimics the early days of internet connectivity when insecure PCs dialed up and were instantly inundated with worms, viruses and email spam. AV/FW software soon came along and intended to reduce those threats.

Today it’s a bit different but the cycle continues.

Back then you’d probably notice that your computer was acting funky, slowing down or malfunctioning since we interacted with it daily. Today, we typically do not spend every waking hour working with our IoT devices. They’re meant to function independently to grab data, make adjustments and alert us on a mobile app with limited human interaction. That’s the ‘smart’ part everyone talks about. But these botnets are smart themselves. With that, you may never know that your DVR is infected and allowing someone across the globe (or waiting at the nearest street corner) watch your every move.

Typical precautions we usually hear are actions like changing default passwords, not connecting it directly to the internet and updating the firmware to reduce the exposure. Software developers, too, need to plan and build in security from the onset rather than an afterthought. The security vs. usability conundrum that plagues many web applications extends to IoT applications also. But you wouldn’t, or I should say, shouldn’t deploy a financial application without properly testing it for vulnerabilities. There the risk is financial loss but with IoT and particularly medical/health devices the result can be deadly.

Mirai was just the beginning of the next wave of vulnerability exploitation. More chaos to come.

ps

Related:

 




Lightboard Lessons: SSO to Legacy Web Applications

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

In this Lightboard Lesson, I draw out how VMware and F5 helps remove these complexities and enable productive, any-device app access. By enabling secure SSO to Kerberos constrained delegation (KCD) and header-based authentication apps, VMware Workspace ONE and F5 BIG-IP APM help workers securely access all the apps they need—mobile, cloud and legacy—on any device anywhere.

 

 

Watch Now:



Managing Your Vulnerabilities

Posted in f5, big-ip, application security, cloud computing, compliance, 0day by psilva on December 9th, 2016

vuln_ahead.jpg

I recently recovered from ACDF surgery where they remove a herniated or degenerative disc in the neck and fuse the cervical bones above and below the disk. My body had a huge vulnerability where one good shove or fender bender could have ruptured my spinal cord. I had some items removed and added some hardware and now my risk of injury is greatly reduced.

Breaches are occurring at a record pace, botnets are consuming IoT devices and bandwidth, and the cloud is becoming a de-facto standard for many companies. Vulnerabilities are often found at the intersection of all three of these trends, so vulnerability and risk management has never been a greater or more critical challenge for organizations.

Vulnerabilities come in all shapes and sizes but one thing that stays constant – at least in computer security - is that a vulnerability is a weakness which allows an attacker to reduce a system’s information assurance. It is the intersection where a system is susceptible to a flaw; whether an attacker can access that flaw; and whether an attacker can exploit that flaw within the system. For F5, it means an issue that results in a confidentiality, integrity, or availability impact of an F5 device by an unauthorized source. Something that affects the critical F5 system functions - like passing traffic.

You may be familiar with CVE or Common Vulnerabilities and Exposures. This is a dictionary of publicly known information security vulnerabilities and exposures. Each vulnerability or exposure gets a name or CVE ID and allows organizations to reference it in a public way. It enables data exchange between security products and provides a baseline index point for evaluating coverage of tools and services. MITRE is the organization that assigns CVEs. There are also CVE Numbering Authorities (CNA). Instead of sending a vulnerability to MITRE for numbering, a CNA gets a block of numbers and can assign IDs as needed. The total CVE IDs is around 79,398.

Most organizations are concerned about CVEs and the potential risk if one is present in their environment. This is obviously growing with the daily barrage of hacks, breaches and information leaks. Organizations can uncover vulnerabilities from scanner results; from media coverage like Heartbleed, Shellshock, Poodle and others; or from the various security related standards, compliance or internal processes. The key is that scanning results need to be verified for false positives, hyped vulnerabilities might not be as critical as the headline claims and what the CVE might mean for your compliance or internal management.

For F5, we keep a close eye on any 3rd party code that might be used in our systems. OpenSSL, BIND or MySQL are examples. For any software, there may be bugs or researcher’s reports or even non-CVE vulnerabilities that could compromise the system. Organizations need to understand the applicability, impact and mitigation available.

Simply put: Am I affected? How bad is it? What can I do?

vuln chart

With Applicability, research typically determines if an organization should care about the vulnerability. Things like, is the version of software noted and are you running it. Are you running the vulnerable function within the software? Sometimes older or non-supported versions might be vulnerable but you’ve upgraded to the latest supported code or you are simply not using the vulnerable function at all. The context is also important. Is it being used in default, standard or recommended mode? For instance, many people don’t change the default password of their Wi-Fi device and certain functionality is vulnerable. It gets compromised and becomes part of a botnet. But if the password was changed, as recommended, and it becomes compromised some other way, then that is a different situation to address.

cvss calculator

For Impact, there are a couple ways to decide how bad it is. First, you can look at the severity of the vulnerability - is it low, medium, high or critical. You can also see if there is a Common Vulnerability Scoring System (CVSS) score tied to the vulnerability. The CVSS score can give you a gauge to the overall risk. To go a bit deeper, you can look at the CVSS Vector.

There are 3 sections to the CVSS. There are the constant base metrics covering the exploitability of the issue, the impact that it may have and the scope that it is in. There are the temporal metrics, which may change over time, giving the color commentary of the issue. And there are the environmental metrics which look at the specific, individual environment and how that is impacted. Areas explored here include things like the attack vector and complexity; whether elevated privileges are required or any user interaction along with the scope and how it affects the confidentiality, integrity and availability of the system. One can use the CVSS calculator to help determine a vector score. With a few selections you can get a base, temporal and environmental score to get an overall view of the severity. With this, you can get an understanding as to how to handle the vulnerability. Every organization has different levels of risk based on their unique situation. The vulnerability base score may have a critical listing yet based on your environmental score, the severity and risk may be nil.

Lastly, the Mitigation taken is not an exact science and truly depends on the issue and the organization’s situation. Mitigation is not necessarily prevention. For example, compensating controls, such as restricting root level access might mean that a vulnerability simply isn’t exploitable without a privileged account.

Vulnerability management and information security is about managing risk. Risk analysis, risk management, risk mitigation and what that risk means to the business. Patching a vulnerability can introduce other risks, so the old refrain of “patch your $#!+” is not the panacea we’re often led to believe. Risk is not limited to the severity of the vulnerability alone, but also to the required vector for exploiting that vulnerability where it exists within a specific organization’s infrastructure.

It’s important to understand your risk and focus on the important pieces.

ps




Your SSL Secrets Uncovered

Posted in f5, big-ip, application security, adc, application delivery, access by psilva on December 9th, 2016

Get Started with SSL Orchestrator

SSL and its brethren TLS is becoming more prevalent to secure IP communications on the internet. It’s not just financial, health care or other sensitive sites, even search engines routinely use the encryption protocol. This can be good or bad. Good, in that all communications are scrambled from prying eyes but potentially hazardous if attackers are hiding malware inside encrypted traffic. If the traffic is encrypted and simply passed through, inspection engines are unable to intercept that traffic for a closer look like they can with clear text communications. The entire ‘defense-in-depth’ strategy with IPS systems and NGFWs lose effectiveness.

F5 BIG-IP can solve these SSL/TSL challenges with an advanced threat protection system that enables organizations to decrypt encrypted traffic within the enterprise boundaries, send to an inspection engine, and gain visibility into outbound encrypted communications to identify and block zero-day exploits. In this case, only the interesting traffic is decrypted for inspection, not all of the wire traffic, thereby conserving processing resources of the inspecting device. You can dynamically chain services based on a context-based policy to efficiently deploy security.

This solution is supported across the existing F5 BIG-IP v12 family of products with F5 SSL Orchestrator and is integrated with such solutions like FireEye NX, Cisco ASA FirePOWER and Symantec DLP.

Here I’ll show you how to complete the initial setup.

A few things to know prior – from a licensing perspective, The F5 SSL visibility solution can be deployed using either the BIG-IP system or the purpose built SSL Orchestrator platform. Both have same SSL intercept capabilities with different licensing requirements.

To deploy using BIG-IP, you’ll need BIG-IP LTM for SSL offload, traffic steering, and load balancing and the SSL forward proxy for outbound SSL visibility. Optionally, you can also consider the URL filtering subscription to enforce corporate web use policies and/or the IP Intelligence subscription for reputation based web blocking. For the purpose built solution, all you’ll need is the F5 Security SSL Orchestrator hardware appliance.

The initial setup addresses URL filtering, SSL bypass, and the F5 iApps template.

URL filtering allows you to select specific URL categories that should bypass SSL decryption. Normally this is done for concerns over user privacy or for categories that contain items (such as software update tools) that may rely on specific SSL certificates to be presented as part of a verification process.

Before configuring URL filtering, we recommend updating the URL database. This must be performed from the BIG-IP system command line. Make sure you can reach download.websense.com on port 80 via the BIG-IP system and from the BIG-IP LTM command line, type the following commands:

modify sys url-db download-schedule urldb download-now false modify sys url-db

download-schedule urldb download-now true

To list all the supported URL categories by the BIG-IP system, run the following command:

tmsh list sys url-db url-category | grep url-category

Next, you’ll want to configure data groups for SSL bypass. You can choose to exempt SSL offloading based on various parameters like source IP address, destination IP address, subnet, hostname, protocol, URL category, IP intelligence category, and IP geolocation. This is achieved by configuring the SSL bypass in the iApps template calling the data groups in the TCP service chain classifier rules. A data group is a simple group of related elements, represented as key value pairs. The following example provides configuration steps for creating a URL category data group to bypass HTTPS traffic of financial websites.

ssl1.png

ssl2.png

For the BIG-IP system deployment, download the latest release of the iApps template and import to the BIG-IP system.

Extract (unzip) the ssl-intercept-12.1.0-1.5.7.zip template (or any newer version available) and follow the steps to import to the BIG-IP web configuration utility.

ssl3.png

From there, you’ll configure your unique inspection engine along with simply following the BIG-IP admin UI with the iApp questionnaire. You’ll need to select and/or fill in different values in the wizard to enable the SSL orchestration functionality. We have deployment guides for the detailed specifics and from there, you’ll be able to send your now unencrypted traffic to your inspection engine for a more secure network.

ps

Resources:




Lock Down Your Login

Posted in Uncategorized, security, f5, big-ip, application security, silva, authentication, banking, malware, devcentral by psilva on September 27th, 2016

login.png

Last week we talked about WebSafe and how it can help protect against phishing attacks with a little piece of code. This is important since malware can steal credentials from every visited web application from an infected machine. This time we’re going to look at how to protect against credential grabbing on a BIG-IP APM login page with WebSafe encryption layer.

You’ll needtwo modules for this, BIG-IP APM andof course, WebSafe FraudProtection Service. The goal is to protect the laptop from any malware thatgrabs sensitive login credentials. In this case, the malware would beconfigured to grab the login page along with the username and passwordparameter fields. Command and control could also be set to retrieve anycredentials from the infected machine at certain intervals, like every 5minutes.

The first goal would be to encrypt the password. Within your BIG-IP admin GUI, you would navigate to Security>Fraud Protection Service> Anti-Fraud Profiles>URL List. APM’s logon page usually ends with ‘/my.policy’.

mfraudurl.jpg

Create then click that URL to open the configuration page and enable Application Layer Encryption.

mapplayerencrypt.jpg

And select the Parameters tab to configure the fields you want to protect. In this case it is password and username.

mparameters.jpg

In the screen grab, you can see ‘Obfuscate’ is selected and to both ‘Encrypt’ and‘Substitute Value’ for the password field.

Now when the user goes to the page, a bit a JavaScript is injected in the page to protect the specified fields. If you run a httpwatch or wire shark on the page, you’ll see that the values for those parameters are obfuscated. This makes it incredibly difficult for the bad actor to determine the correct value.

mobfuscape.jpg

And if the malware also grabs the password, since we set that to encrypt, all they get is useless information.

mpwuseless.jpg

At this point, the BIG-IP will decrypt the password and pass on the traffic to appropriate domain controller for verification. This is a great way to protect your login credentials with BIG-IP. If you’d like to see a demonstration of this, check out F5’s Security Specialist Matthieu Dierick’s demo video. Pretty cool.

ps




The Dangerous Game of DNS

credit-card-perspective.jpg

The Domain Name Service (DNS) is one of the most important components in networking infrastructure, enabling users and services to access applications by translating URLs (names) into IP addresses (numbers). Because every icon and URL and all embedded content on a website requires a DNS lookup, loading complex sites necessitates hundreds of DNS queries.

And because of that, DNS is a precious target and only lags behind http as the most targeted protocol.

DDoS-ing DNS is an effective way to make the service unavailable. As the flood of malicious DNS requests hit the infrastructure, the service can become unresponsive if there is not enough capacity. Organizations can add more servers or turn to their cloud-based security provider for help. One of the strategies cloud-based security providers use to shield DNS is DNS redirection. Cloud providers will divert incoming traffic to their own infrastructure, which is resilient enough to detect and absorb these attacks. The success of this strategy however depends on how well the website's original IP address can be shielded. If the bad guy can find that IP address, then they can get around the protection.

So is DNS redirection effective? Researchers decided to find out.

Scientists from KU Leuven in Belgium built a tool called CLOUDPIERCER, which automatically tries to retrieve websites' original IP address, including the use of unprotected subdomains. Almost 18,000 websites, protected by five different providers, were part to the team's DNS redirection vulnerability tests. In more than 70% of the cases, CLOUDPIERCER was able to retrieve the website's original IP address - the precise info needed to launch a successful attack.

Researchers did share their findings with those cloud-based providers and have made CLOUDPIERCER freely available for organizations to test their own DNS infrastructure.

In another DNS scam, a new version of the NewPosThings PoS (point of sale, not…) malware is using DNS rather than http/https/ftp to extract data from infected PoS terminals. This is an interesting twist since most security solutions monitor http/https traffic for suspicious activity. Anti-virus doesn’t necessarily watch DNS and admins cannot simply turn off DNS since they need it to resolve hostnames and domains. Seems like a clear shot.

The newest version of NewPoSThings is nicknamed MULTIGRAIN and it only targets (and infects) one specific type of PoS platform: The multi.exe process, specific to a popular electronic draft capture software package. If the multi.exe process is not found the malware moves on. Once inside, the malware waits for the Track 2 credit card data and once it has the data, it encrypts and encodes it before sending to the bad guy via a DNS query.

The use of DNS for data exfiltration on PoS devices is not new and shows not only how attackers can adjust to different environments but also, that organizations need to be more aware of their DNS traffic for potential anomalies.

BIG-IP could also help in both instances.

For the redirection issue, BIG-IP or our Silverline Managed Service offers Proxy mode with DNS redirection. With Routed Mode, we offer BGP to Silverline then Generic Routing Encapsulation (GRE) tunnels or L2VPN back to the customer to mask the original IP address.

For the PoS malware, BIG-IP can utilize a DNS response policy zone (RPZ) as a firewall or outbound domain filtering mechanism. An RPZ is a zone that contains a list of known malicious Internet domains. The list includes a resource record set (RRset) for each malicious domain and each RRset includes the names of the malicious domain and any subdomains of the domain.

When the BIG-IP system receives a DNS query for a domain that is on the malicious domain list of the RPZ, the system responds in one of two ways based on your configuration. You can configure the system to return an NXDOMAIN record that indicates that the domain does not exist or return a response that directs the user to a walled garden.

rpz1.png

BIG-IP returns NXDOMAIN response to DNS query for malicious domain

rpz2.png

BIG-IP forwards DNS query for malicious domain to walled garden

DNS is one of those technologies that is so crucial for a functioning internet, especially for human interaction. Yet is often overlooked or seems to only get attention when things are broken. Maybe take a gander today to make sure your DNS infrastructure is secure, scalable and ready to answer each and every query. Ignoring DNS can have grave consequences.

ps

Related:




Plugging Data Leaks

dataharvest.png

Whether intentional or accidental, data leaks are a huge concern for organizations. And it has been for years. Going back to a 2004 survey from an IT security forum hosted by Qualys, found that 67% of security executives do not have controls in place to prevent data leakage, A December 2006 survey, Boston-based researchers Simon Management Group noted that some 78% of respondents said they were "very concerned" about data exposure. A 2010 article published by Trustwave on CSOonline.comsaid that 65% of leakage occurs due to the following combined methods: Microsoft SMB sharing, Remote Access Applications, and Native FTP clients.

And a recent informal survey conducted by the Avast Mobile Enterprise team at two healthcare technology events indicates that Data Leakage (69%) was the greatest security concern of Healthcare CISOs. Insider threats (34%) and Malware (28%) got silver and bronze.

Information seems to be the gold standard in today’s digital society and it comes in many forms. It can be personally identifiable information (PII) of customers or employees; it can be corporate or financial info; it can be litigation related; it can also be health care related and really, any data that should be kept secret…except from those who are authorized to view it.

According to Cisco, some risky behavior by employees can aggravate the situation. Areas included:

  • Unauthorized application use: 70% of IT professionals believe the use of unauthorized programs resulted in as many as half of their companies' data loss incidents.
  • Misuse of corporate computers: 44% of employees share work devices with others without supervision.
  • Unauthorized physical and network access: 39% of IT professionals said they have dealt with an employee accessing unauthorized parts of a company's network or facility.
  • Remote worker security: 46% of employees admitted to transferring files between work and personal computers when working from home.
  • Misuse of passwords: 18% of employees share passwords with co-workers. That rate jumps to 25 percent in China, India, and Italy.

How can you reduce and mitigate some data leakage risks? BIG-IP can help shore up some areas.

The overall category of Data Loss Prevention (DLP) is a multi-faceted area of security that encompasses securing data storage, data transmission, and data in-use. Specifically, BIG-IP ASM focuses on the protection of data in-flight. For instance, ASM’s DataGuard is a method of protecting against SSN or CC# information from leaking out of back-end databases but ASM’s benefits in a DLP strategy extend well beyond that. DLP is concerned with unauthorized access to any private data, whether confidential personal or corporate information. ASM provides comprehensive protection against unauthorized back-end database access, by preventing the exploit of well-known vulnerabilities such as XSS, SQL-injection, cookie poisoning, etc. If you can’t even reach the info, less likelihood of it leaking.

No single product is going to provide a comprehensive, all inclusive DLP solution. HIPAA, PCI, and other regulatory standards are focused almost entirely on DLP. BIG-IP ASM, as a WAF, provides a vital part of any overall DLP solution in today’s security-conscious environment.

ps

Related:





« Older episodes ·