Smartphones have become an integral part of our lives; we rely on them for everything. They hold all of our personal information, calendars, emails, phone numbers, text messages, and documents. However, the average user is not very savvy when it comes to the security of these devices. A user can browse to one of the many app stores and download just about anything, and most users do just that. One of the exciting things about smartphones is the customization of them. You can get any type of application you want, and most of the time it is free. You can get games, productivity applications, web servers, and ftp servers. Users feel a false sense of security because it is “just a phone” and the apps must be secure because they are getting them from an app store. These apps are developed by programmers of varying levels and skill sets, and security might not be their top priority. None of the app stores put the apps through a thorough security check; most run virus scans but it is usually done randomly and done after the app is posted. Even Apple has fallen victim to mobile malware. Some apps have even been signed safe by the stores only to have malicious code be discovered at a later date. Samsung’s Wave shipped with malware installed on the SD card, which activated as soon as it was connected to a PC.
Read more!
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Thursday, June 17, 2010
Thursday, October 8, 2009
What’s the Value of Your Mobile Phone’s Address Book?
Being a consultant, I travel a good amount around the United States for various engagements. While at airports, hotels, and other public places that offer opportunities for wireless communications, I often find myself in amazement of the information at large.
Approximately 4 months ago, I sat at the airport gate awaiting my incoming flight and a woman sitting next (2 seats down, or about 6 feet away) to me was talking on her cell phone about her travel reservations. Whomever she was speaking with apparently had Internet access as she gave them instructions on how to open up Internet Explorer, navigate to www..com, and login with a username of and password of . She proceeded to instruction this person how to search for a hotel, and book a reservation, also giving her credit card number, expiration date, and CV2 code. After she hung up from the call, I thought to myself that it would be very amusing to go thank her for her information and paying for my flight/hotel. Of course, I did not, but thought to myself how clueless must this lady be.
From airports to hotels, it is no surprise that there are always open file shares, shared iTunes libraries, and similar things readily available to people via Bluetooth or wireless communications. This is nothing new, however the sensitivity of the information people purposely or inadvertently have shared varies. When doing a penetration test for a large health care organization, a coworker and I gained access to a Web site that was indexed in Google that provided us with a complete employee directory listing. This client was alarmed at what we found, as we could couple this gold mine of internal information with some XSS flaws to perform a large scale phishing attack.
I pose this question: How important to your organization is your mobile phone’s phonebook?
More specifically, the Apple iPhone’s use for the corporate world has been a topic of debate for some time. With the number of applications in the AppStore, how well do you think Apple is doing screening them all for rogue code? Just as an organization has that fear of a time bomb planted by and ex-developer in one of its code bases, should iPhone users and enterprises be worried about your information on their iPhone? The answer is yes.
Code showing how to read not only your iPhone’s number, but also your entire address book as well has been published online for some time now. Additionally, the article claims that applications can obtain personal information from most of the iPhone’s file system despite Apple having a developer sandbox in place. We’ve already seen the $999.99 “I am Rich” app that tricked 8 people into its $1,000 price tag, so what else might exist in the thousands of other applications available? Do your C-level executives use an iPhone? Has your address book or theirs already been compromised? You may never know…
Read more!
Approximately 4 months ago, I sat at the airport gate awaiting my incoming flight and a woman sitting next (2 seats down, or about 6 feet away) to me was talking on her cell phone about her travel reservations. Whomever she was speaking with apparently had Internet access as she gave them instructions on how to open up Internet Explorer, navigate to www.
From airports to hotels, it is no surprise that there are always open file shares, shared iTunes libraries, and similar things readily available to people via Bluetooth or wireless communications. This is nothing new, however the sensitivity of the information people purposely or inadvertently have shared varies. When doing a penetration test for a large health care organization, a coworker and I gained access to a Web site that was indexed in Google that provided us with a complete employee directory listing. This client was alarmed at what we found, as we could couple this gold mine of internal information with some XSS flaws to perform a large scale phishing attack.
I pose this question: How important to your organization is your mobile phone’s phonebook?
More specifically, the Apple iPhone’s use for the corporate world has been a topic of debate for some time. With the number of applications in the AppStore, how well do you think Apple is doing screening them all for rogue code? Just as an organization has that fear of a time bomb planted by and ex-developer in one of its code bases, should iPhone users and enterprises be worried about your information on their iPhone? The answer is yes.
Code showing how to read not only your iPhone’s number, but also your entire address book as well has been published online for some time now. Additionally, the article claims that applications can obtain personal information from most of the iPhone’s file system despite Apple having a developer sandbox in place. We’ve already seen the $999.99 “I am Rich” app that tricked 8 people into its $1,000 price tag, so what else might exist in the thousands of other applications available? Do your C-level executives use an iPhone? Has your address book or theirs already been compromised? You may never know…
Read more!
Friday, March 6, 2009
Firewall Ruleset Review
I’ve done a lot of firewall ruleset reviews for companies large and small. There is a pattern forming in almost every firewall I’ve seen.
Bad management.
It’s not about blaming people though. The economy is in the sewer and layoffs plague every company across the planet. Most every security team is dealing with tons of ongoing work to stay secure and low budgets and resources to get the job done.
The firewall rule sets I’ve seen range from 50 lines to 10,000+ lines. Some are so complex that we schedule a week of work to audit and determine what can be taken out, what needs to stay and what shouldn’t have been there in the first place.
Let’s face it; many firewalls have dead rules, non-existent networks and “permit any” rules. Those are the low lying fruit that we look for first and when fixed, automatically increase security surrounding the attached networks.
Any access list that ends in “permit ip any any” is wasted CPU power and increased RAM usage. Why make your firewall go thru all of those rules if you permit everything at the end anyways? Not to mention, if you’re going to do that, you could have saved yourself hundreds or thousands of dollars and just gotten a router and used static routes to forward traffic. But in the security world that isn’t an option.
Too often we see timeout settings that are too large, insecure protocols being used and lack of ingress or egress rules. The worst cases are the firewalls that are built backwards (a whole slew of deny statements followed by a permit any statement).
Overall, the largest issue is lack of egress filtering. Time and time again, we run into this. And in many of our assessments we capitalize on this. In both Social Engineering attacks and Penetration tests we are able to accomplish many tasks by using these lax rules. Even if you aren’t worried about the next major virus or worm, you should care in not helping spread the infection. Close your doors and be a good neighbor!
All of these issues add up to the sum of bad network security which is caused by bad management. There needs to be process and documentation of all rules and configuration settings within a configuration. Asking “Hey Chuck, there’s a strange rule in here, did you do that?” doesn’t count as documentation either.
At the end of the day, if you skip on a little security here and a little security there, what’s the point of implementing high dollar equipment? If you’re going to implement your firewall properly you should have dedicated process behind the ruleset. Justify every rule, every business segment, set it, and forget it. There should be no need to constantly be modifying your firewall. I can see the need if you’re installing a new server or software package, but adding and dropping lines daily or even weekly is not efficient use of anyone’s time.
The moral of the story is, if you are making constant changes, have bad rules, or an insecure configuration, then you should start over and build your configuration properly. A regular audit of the firewall ruleset is always a good idea and should be budgeted for. Put in the proper change control, documentation and justification, and you will be amazed how much more secure your network will become.
Read more!
Bad management.
It’s not about blaming people though. The economy is in the sewer and layoffs plague every company across the planet. Most every security team is dealing with tons of ongoing work to stay secure and low budgets and resources to get the job done.
The firewall rule sets I’ve seen range from 50 lines to 10,000+ lines. Some are so complex that we schedule a week of work to audit and determine what can be taken out, what needs to stay and what shouldn’t have been there in the first place.
Let’s face it; many firewalls have dead rules, non-existent networks and “permit any” rules. Those are the low lying fruit that we look for first and when fixed, automatically increase security surrounding the attached networks.
Any access list that ends in “permit ip any any” is wasted CPU power and increased RAM usage. Why make your firewall go thru all of those rules if you permit everything at the end anyways? Not to mention, if you’re going to do that, you could have saved yourself hundreds or thousands of dollars and just gotten a router and used static routes to forward traffic. But in the security world that isn’t an option.
Too often we see timeout settings that are too large, insecure protocols being used and lack of ingress or egress rules. The worst cases are the firewalls that are built backwards (a whole slew of deny statements followed by a permit any statement).
Overall, the largest issue is lack of egress filtering. Time and time again, we run into this. And in many of our assessments we capitalize on this. In both Social Engineering attacks and Penetration tests we are able to accomplish many tasks by using these lax rules. Even if you aren’t worried about the next major virus or worm, you should care in not helping spread the infection. Close your doors and be a good neighbor!
All of these issues add up to the sum of bad network security which is caused by bad management. There needs to be process and documentation of all rules and configuration settings within a configuration. Asking “Hey Chuck, there’s a strange rule in here, did you do that?” doesn’t count as documentation either.
At the end of the day, if you skip on a little security here and a little security there, what’s the point of implementing high dollar equipment? If you’re going to implement your firewall properly you should have dedicated process behind the ruleset. Justify every rule, every business segment, set it, and forget it. There should be no need to constantly be modifying your firewall. I can see the need if you’re installing a new server or software package, but adding and dropping lines daily or even weekly is not efficient use of anyone’s time.
The moral of the story is, if you are making constant changes, have bad rules, or an insecure configuration, then you should start over and build your configuration properly. A regular audit of the firewall ruleset is always a good idea and should be budgeted for. Put in the proper change control, documentation and justification, and you will be amazed how much more secure your network will become.
Read more!
Tuesday, August 5, 2008
Preparing for HIPAA: Round Two - The Audit
The big buzz this year around security assessments and audits is all about HIPAA. This was #6 in SecureState's Top 8 of 08 and, to say the least, there’s quite a bit of tension in the air as organizations hold their breath. While PCI is still the most active, all of our clients with HIPAA concerns – which is many – are on constant watch to see what HIPAA is really going to mean. To date, HIPAA has been a little weak as organizations have been left to their own devices to operate around a risk-based approach for HIPAA. But that approach has time and time again proven to not be diligent enough and/or favors the business over security. But now, the audits are happening, HIPAA is getting some teeth, and most organizations are scrambling to figure out what ‘their’ interpretation is and if what they did is enough. Everyone knows that the first audit was done last year at a hospital and have seen the list of‘42 questions’ that were asked. But those hardly helped as they really didn’t indicate what the expectations were. Now other HIPAA organizations are being audited including retailers and insurers. The results are supposed to be posted on the CMS/HHS site, but so far nothing is out there. But hope is not lost as the details emerge from our clients and other information.
First of all, it is important to realize who is doing the audits. It is KPMG’s government practice and working for a government agency. As such, it should be expected that they would leveraging NIST standards. The second indicator is from NIST itself. The CMS/HHS first worked with NIST to develop the 800-66 publication for understanding and implementing the HIPAA Security Rule. But that proved to be fairly vague and mainly referencing a bunch of other NIST standards but not providing a lot of ‘how’. Based on that type of feedback, they have issued a draft version ( http://csrc.nist.gov/publications/drafts/800-66-Rev1/Draft_SP800-66-Rev1.pdf ) that has finally provided a solid understanding of how to implement the Security Rule – by mapping it to NIST 800-53 that outlines ‘recommended controls’, not unlike ISO 27002 (formerly 17799). Ultimately, this has been further confirmed in reviewing some of the HIPAA audit draft reports that NIST 800-53 is the core of the KPMG audit framework.
So now you know what they are looking for and what to expect. If you were looking for a solid ‘checklist’ for gapping your HIPAA program, look no further than NIST 800-53, or even better, the draft of NIST 800-66. The draft is great as it also has sample questions that the auditor might be asking as well – hint hint. The other referenced NIST standards can also be helpful, especially if your organization uses a particular technology extensively e.g. 800-124 draft on cell/PDA security. Regardless of what the checklist is, the bottom line is HIPAA has not had a strong enough impact for organizations, much like SOX. As a result, companies aren’t really getting secure as originally intended. Every hospital or insurance company we have reviewed has failed system audits and penetration testing - and we're the good guys. Getting compliant, even to a higher level, isn’t getting secure. And odds are, your organization has more than HIPAA data out there.
So do the right thing, do due diligence, do it soon, and get your organization to a defensible position before the audit. Base your decisions on the intent of the controls outlined in 800-53/66, not the wording or sample interpretation. Don't wait for the audit, findings and fines - or even worse - the breach. It's a lot more expensive to implement security after the fact than before.
Read more!
First of all, it is important to realize who is doing the audits. It is KPMG’s government practice and working for a government agency. As such, it should be expected that they would leveraging NIST standards. The second indicator is from NIST itself. The CMS/HHS first worked with NIST to develop the 800-66 publication for understanding and implementing the HIPAA Security Rule. But that proved to be fairly vague and mainly referencing a bunch of other NIST standards but not providing a lot of ‘how’. Based on that type of feedback, they have issued a draft version ( http://csrc.nist.gov/publications/drafts/800-66-Rev1/Draft_SP800-66-Rev1.pdf ) that has finally provided a solid understanding of how to implement the Security Rule – by mapping it to NIST 800-53 that outlines ‘recommended controls’, not unlike ISO 27002 (formerly 17799). Ultimately, this has been further confirmed in reviewing some of the HIPAA audit draft reports that NIST 800-53 is the core of the KPMG audit framework.
So now you know what they are looking for and what to expect. If you were looking for a solid ‘checklist’ for gapping your HIPAA program, look no further than NIST 800-53, or even better, the draft of NIST 800-66. The draft is great as it also has sample questions that the auditor might be asking as well – hint hint. The other referenced NIST standards can also be helpful, especially if your organization uses a particular technology extensively e.g. 800-124 draft on cell/PDA security. Regardless of what the checklist is, the bottom line is HIPAA has not had a strong enough impact for organizations, much like SOX. As a result, companies aren’t really getting secure as originally intended. Every hospital or insurance company we have reviewed has failed system audits and penetration testing - and we're the good guys. Getting compliant, even to a higher level, isn’t getting secure. And odds are, your organization has more than HIPAA data out there.
So do the right thing, do due diligence, do it soon, and get your organization to a defensible position before the audit. Base your decisions on the intent of the controls outlined in 800-53/66, not the wording or sample interpretation. Don't wait for the audit, findings and fines - or even worse - the breach. It's a lot more expensive to implement security after the fact than before.
Read more!
Tuesday, July 22, 2008
PCI Compliance: Close but no cigar.
PCI Compliance is on almost everyone's mind and it will continue to grow in popularity as time progresses. Before I start, this is by no means a rant or flaming of the PCI DSS 1.1 standard, in fact, to date the PCI DSS is the most technical security framework really out there to date. There are a lot of positives toward the standard; however it has many shortcomings. I'm not going to list every one, but focus on some of the most pressing issues that we've seen as penetration testers and where the standard really is failing.
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
Thursday, July 17, 2008
Take the A out of the CIA model for Information Security
Have you ever wondered why Availability is included in the Confidentially, Integrity and Availability model? I did… and wrote this blog to express my thoughts.
Wikipedia definition “Information Security is concerned with the confidentiality, integrity and availability of data regardless of the form the data may take: electronic, print, or other forms.”
Hmmm, okay. But why should I, as a security professional, be worried about the availability of the data? The way I see it, if the information is unavailable… then that is better. I believe the Payment Card Industry (PCI) standard was the first regulation to catch on to this. If you read the standard it doesn’t mention the availability, back up or recovery of data, and being a Qualified Security Assessor (QSA), I understand the PCI Council has good reasons why.
As a security professional I understand that the evolution of security. Back in the day… security meant having a firewall and making sure that network was available. However, today security has a completely different role within organization. The ability for the information to be available falls under the jurisdiction of the Chief Information Officer.
I have authored hundreds of security documents that if/when implemented would “break” the functionality of the application, system or process. However, if these controls are not implemented the application, system or process is left vulnerable to attack. Being concerned with availability, you, as the security professional cannot push the implementation of the control. As such, you have accepted the vulnerability.
Why is this important? Many organizations are unable to position Security in the right structure, meaning that security still falls under the CIO. While this can work, there are too many points of failure for security to be embraced within the organization. So, as long as security professionals continue to position themselves with the responsibility of ensuring availability of information, the ability to truly secure the data will be jeopardized.
Read more!
Wikipedia definition “Information Security is concerned with the confidentiality, integrity and availability of data regardless of the form the data may take: electronic, print, or other forms.”
Hmmm, okay. But why should I, as a security professional, be worried about the availability of the data? The way I see it, if the information is unavailable… then that is better. I believe the Payment Card Industry (PCI) standard was the first regulation to catch on to this. If you read the standard it doesn’t mention the availability, back up or recovery of data, and being a Qualified Security Assessor (QSA), I understand the PCI Council has good reasons why.
As a security professional I understand that the evolution of security. Back in the day… security meant having a firewall and making sure that network was available. However, today security has a completely different role within organization. The ability for the information to be available falls under the jurisdiction of the Chief Information Officer.
I have authored hundreds of security documents that if/when implemented would “break” the functionality of the application, system or process. However, if these controls are not implemented the application, system or process is left vulnerable to attack. Being concerned with availability, you, as the security professional cannot push the implementation of the control. As such, you have accepted the vulnerability.
Why is this important? Many organizations are unable to position Security in the right structure, meaning that security still falls under the CIO. While this can work, there are too many points of failure for security to be embraced within the organization. So, as long as security professionals continue to position themselves with the responsibility of ensuring availability of information, the ability to truly secure the data will be jeopardized.
Read more!
Subscribe to:
Posts (Atom)
Posts
