Everywhere you look, there are articles, research and analysis on the topic of cloud computing. It has even been termed, “the most significant shift in information technology in our lifetimes.” The positive aspects are exciting and offer many benefits, including access to applications, storage for legacy data, and powerful computer processing -all with the click of a mouse. For companies that want to avoid purchasing entire systems of IT software and hiring the talent to operate and secure them, this option may seem very tempting. One common concern that should be analyzed and researched thoroughly is the issue of security in cloud computing. Any future cloud user should gather as much information as possible about their potential cloud provider before sending any data to the cloud.
For instance, it would be wise to ask any potential cloud provider how they protect against malicious insider activity. One question that should be submitted is if a provider conducts background checks on all relevant employees. Nothing like sending PII to a cloud provider that lacks knowledge on who is working for them. Additionally, questions on employee monitoring, access determination, and audit trails would also be appropriate. Some providers may not want to divulge such technical information. If the cloud provider does not want to provide such information, ask if they have any monitoring and access control policies and procedures in place. If they don’t, tell them to create some and make it part of the service contract. One way or another, you’re going to want to be protected.
For those cloud providers that are providing Software as a Service where all development is handled on the provider side, questions on the system development lifecycle would apply. For example, customers will want to know if the cloud provider has incorporated security into their SDLC. Also, see if the future cloud provider takes into consideration the OWASP Cloud Top 10 during the development cycle. Lastly, ask the provider if they follow Cloud Security Alliance guidance for critical focus areas. If the cloud provider answers in the negative or has no idea what you’re talking about, it may be best to look for another provider.
As touched on above, some cloud computing companies practice the “security by obscurity” method, which will usually exacerbate the fears of the company seeking cloud services. It is a fine line to walk, because the cloud computing company does not want to divulge too much information, which could compromise their security from malicious attackers. However they should want to be as transparent as possible to their potential clients. Try to find a cloud computing company that offers voluntary monthly or quarterly security reports. This report will show the client what issues the company is addressing, without broadcasting information that compromises their security posture.
What other types of data are being stored by the cloud provider? Do they allow data that may be malicious code, spamming data or information related to criminal activity? In multi-tenant environments “Innocent” data can be located on the same shared infrastructure as “Malicious” data. This should be investigated thoroughly before choosing a cloud provider. Specific questions about strict registration and validation processes and ongoing monitoring of network traffic before, after and during storage and use should be the norm. Besides, if the provider accepts unscrupulous clients and the provider’s defense in depth as well as compartmentalization is weak, what’s to stop a malicious tenant from accessing your data?
Before utilizing any cloud services, customers should conduct an internal assessment for any regulatory compliance complications. Many regulations demand that certain classes of data not be intermingled with other, less sensitive data, such as on multi-tenant shared servers or databases. Additionally, data retention laws vary among countries, with data limits on what can be stored, and for how long being heavily regulated in some countries. Some countries even make it unlawful for some data to be transferred to foreign cloud providers. When the data is no longer needed, most retention laws will require the cloud provider to wipe the data clean before being sent to the pool. Can your cloud provider provide this service? Also, many regulations or standards require some sort of logging as well as log reviewing to be conducted in order to be compliant (PCI Anybody). However, most cloud provider logs are internal and access to these logs by customers or auditors may be difficult. As a result, this type of scenario would make complying with such regulation or standard nearly impossible. Consequently, a compliance impact assessment should be carried out before moving to the cloud.
In conclusion, there are many concerns that companies must consider before utilizing the Cloud. The concerns highlighted in this blog post are only the tip of the iceberg. Therefore, a proper assessment of any cloud provider is warranted for any organization planning a move to the cloud.
Read more!
Thursday, August 5, 2010
Tuesday, August 3, 2010
Information Security Policies and Procedures, Part 1
Note: This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Monday, August 2, 2010
Vulnerability Assessments are not Penetration Tests!
Too often I, as well as many of my co-workers, go into a client and throughout whatever assessment I am working on, general questions come up like, “when’s the last time you’ve had a pen test?” And the client responds, “Ohhh, we do those annually with ‘Some Corporation.’ ” And after looking at ‘Some Corporation’s’ website and seeing what they consider to be a penetration test, I am again disgusted to see that they show up with a vulnerability scanner, run it, validate some findings, and are off to their next client.
Now I know these are some brash comments made toward some random security companies, but let’s be honest here: If you’re going to do something, do it right the first time and provide your client the value of the assessment they paid for. Additionally, give the client what they paid for. If I go to a salesman to buy a sports car and he tries to sell me a Honda Civic, I’m going somewhere else to get what I asked for. On the other side of the coin is the fact that a lot of companies that want a penetration test don’t really understand what it is to begin with. It seems to me that gone are the days of true pen testing when the dreaded “Red Team” shows up to strike real fear into the hearts and minds of Security Practitioners at Fortune 1000 companies.
Any kid in their parent’s basement with savvy computer skills can fire up a Nessus scanner, Web Application Scanners, or Qualys Guard against a network and some of those people can actually interpret the results to make sense out of them. Trust me, everyone on SecureState’s Profiling Team can do that with their eyes closed, but how many security companies out there can actually run a legitimate pen test? I’m not calling anyone out and challenging them, but in all reality, I just want to know how many companies are willing to admit that what they call a “Penetration Test” is actually just a vulnerability assessment? Even worse is the number of companies who perform so called “penetration tests” and truly believe that a vulnerability assessment is the same thing as a pen test.
So let’s all be clear here: a true penetration test is over 85 percent manual and the remaining 15 percent can be a vulnerability scanner to get some other findings in a report in order to provide additional value to the client. And let’s also define manual attacks as to not be ruling out all tools. Using a port scanner is way different than using nCircle, Qualys, or Nessus. Automated scanners like these are the tools that don’t really help a pen test. And just because you use a tool like the Metasploit Framework and many of the tools in Back|Track 4, doesn’t mean you are running a vulnerability scanner. NMAP has the ability to run scripts as well, but again, it doesn’t belong in the Vulnerability Scanner category.
Many times, companies perform Attack and Penetration's due to compliance, or potentially other reasons, which is a bad idea. It gives those companies the opportunity to choose malicious compliance over the desire for truly assessing the security of the entire company. Malicious compliance is a term used when companies do the bare minimum in order to achieve a stamp of approval for whatever standards they are trying to satisfy the needs of. When companies choose to perform pen tests on only their systems affected by compliance, such as PCI or HIPAA systems, they are missing entire networks of systems which aren’t tested. When this happens, companies aren’t getting the true value of what a Pen Test can provide.
SecureState is a trend setting company, and this is where we are going to step in and say, “We Pen Test!” The PCI DSS Council has at least defined what they consider a penetration test. In section 11.3 the Council defines it to be: “vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.” Even the EC Council states that, “Penetration testing simulates methods that intruders use to gain unauthorized access to an organization’s networked systems and then compromise them. Penetration testers may use proprietary and/or open source tools to test known technical vulnerabilities in networked systems. Apart from automated techniques, penetration testing involves manual techniques for conducting targeted testing on specific systems to ensure that there are no security flaws that may have gone undetected earlier.”
The SecureState Profiling Team utilizes lower risk vulnerabilities in some systems with additional vulnerabilities in other systems and links them together into larger attacks. By pulling off an attack in this fashion, the Profiling Team utilizes what is called the Vulnerability Linkage Theory in which we can show why it's important to maintain system baselines and other security measures. The Vulnerability Linkage Theory shows how the attack was pulled off by coupling vulnerabilities in many systems to result in the end compromise. For instance, username enumeration from a website, coupled with a brute force attack on the mail system, could allow SecureState to access mail from a company. From here we can email the tech support team and social engineer them into divulging information on how to access the corporate VPN and voila: access to the internal corporate network. There is no way a vulnerability scanner can do that.
Penetration tests zero in to specific systems in order to break in and see what information can be divulged. Pilfering computers and file shares will explain the benefits of Pen Tests by finding the important documents and unencrypted data. Even finding password protected Microsoft Office files can be cracked to release potentially serious data about a company we’re hacking into. Pen Tests can also be used by Security Departments to show why things need to be fixed and get budget to move forward.
There are conflicting views on Pen Tests and Vulnerability Scans. Pen Tests aren’t performed to find vulnerabilities; they are done in order to compromise systems and networks. The main difference between the two is that in a pen test the attackers are actually exploiting vulnerabilities in systems, adding user accounts, and compromising machines across the network. A full or total compromise, which means total control over the entire network, is the end goal of a pen test. Throughout a pen test, the attackers will inevitably generate a list of findings. Many of these findings may be the same as what a vulnerability assessment will also come up with, but there are many vulnerabilities that scanners just can’t find, which leads to the fact that tools can’t think; consultants can. Consultants are able to interpret results and decide on how to use them in order to leverage certain attack vectors against machines and networks.
Don’t get me wrong: I am not discounting the need, want, or value of a vulnerability assessment. These assessments, as well as pen tests, have their place and need. What I am saying is that these assessments need to be better understood in order to know how and when they should be performed. Additionally, there have been companies that run regular vulnerability assessments and the same vulnerabilities keep coming up every single scan. These companies are either overwhelmed with the amount of vulnerabilities present in their networks and don’t know how to fix them, or they don’t see the value or need in fixing them. Penetration tests can enforce the reasoning. In turn, by better understanding what the difference is, the clients will understand what to expect as a final product and won’t be dissatisfied with the results of each test.
Read more!
Now I know these are some brash comments made toward some random security companies, but let’s be honest here: If you’re going to do something, do it right the first time and provide your client the value of the assessment they paid for. Additionally, give the client what they paid for. If I go to a salesman to buy a sports car and he tries to sell me a Honda Civic, I’m going somewhere else to get what I asked for. On the other side of the coin is the fact that a lot of companies that want a penetration test don’t really understand what it is to begin with. It seems to me that gone are the days of true pen testing when the dreaded “Red Team” shows up to strike real fear into the hearts and minds of Security Practitioners at Fortune 1000 companies.
Any kid in their parent’s basement with savvy computer skills can fire up a Nessus scanner, Web Application Scanners, or Qualys Guard against a network and some of those people can actually interpret the results to make sense out of them. Trust me, everyone on SecureState’s Profiling Team can do that with their eyes closed, but how many security companies out there can actually run a legitimate pen test? I’m not calling anyone out and challenging them, but in all reality, I just want to know how many companies are willing to admit that what they call a “Penetration Test” is actually just a vulnerability assessment? Even worse is the number of companies who perform so called “penetration tests” and truly believe that a vulnerability assessment is the same thing as a pen test.
So let’s all be clear here: a true penetration test is over 85 percent manual and the remaining 15 percent can be a vulnerability scanner to get some other findings in a report in order to provide additional value to the client. And let’s also define manual attacks as to not be ruling out all tools. Using a port scanner is way different than using nCircle, Qualys, or Nessus. Automated scanners like these are the tools that don’t really help a pen test. And just because you use a tool like the Metasploit Framework and many of the tools in Back|Track 4, doesn’t mean you are running a vulnerability scanner. NMAP has the ability to run scripts as well, but again, it doesn’t belong in the Vulnerability Scanner category.
Many times, companies perform Attack and Penetration's due to compliance, or potentially other reasons, which is a bad idea. It gives those companies the opportunity to choose malicious compliance over the desire for truly assessing the security of the entire company. Malicious compliance is a term used when companies do the bare minimum in order to achieve a stamp of approval for whatever standards they are trying to satisfy the needs of. When companies choose to perform pen tests on only their systems affected by compliance, such as PCI or HIPAA systems, they are missing entire networks of systems which aren’t tested. When this happens, companies aren’t getting the true value of what a Pen Test can provide.
SecureState is a trend setting company, and this is where we are going to step in and say, “We Pen Test!” The PCI DSS Council has at least defined what they consider a penetration test. In section 11.3 the Council defines it to be: “vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.” Even the EC Council states that, “Penetration testing simulates methods that intruders use to gain unauthorized access to an organization’s networked systems and then compromise them. Penetration testers may use proprietary and/or open source tools to test known technical vulnerabilities in networked systems. Apart from automated techniques, penetration testing involves manual techniques for conducting targeted testing on specific systems to ensure that there are no security flaws that may have gone undetected earlier.”
The SecureState Profiling Team utilizes lower risk vulnerabilities in some systems with additional vulnerabilities in other systems and links them together into larger attacks. By pulling off an attack in this fashion, the Profiling Team utilizes what is called the Vulnerability Linkage Theory in which we can show why it's important to maintain system baselines and other security measures. The Vulnerability Linkage Theory shows how the attack was pulled off by coupling vulnerabilities in many systems to result in the end compromise. For instance, username enumeration from a website, coupled with a brute force attack on the mail system, could allow SecureState to access mail from a company. From here we can email the tech support team and social engineer them into divulging information on how to access the corporate VPN and voila: access to the internal corporate network. There is no way a vulnerability scanner can do that.
Penetration tests zero in to specific systems in order to break in and see what information can be divulged. Pilfering computers and file shares will explain the benefits of Pen Tests by finding the important documents and unencrypted data. Even finding password protected Microsoft Office files can be cracked to release potentially serious data about a company we’re hacking into. Pen Tests can also be used by Security Departments to show why things need to be fixed and get budget to move forward.
There are conflicting views on Pen Tests and Vulnerability Scans. Pen Tests aren’t performed to find vulnerabilities; they are done in order to compromise systems and networks. The main difference between the two is that in a pen test the attackers are actually exploiting vulnerabilities in systems, adding user accounts, and compromising machines across the network. A full or total compromise, which means total control over the entire network, is the end goal of a pen test. Throughout a pen test, the attackers will inevitably generate a list of findings. Many of these findings may be the same as what a vulnerability assessment will also come up with, but there are many vulnerabilities that scanners just can’t find, which leads to the fact that tools can’t think; consultants can. Consultants are able to interpret results and decide on how to use them in order to leverage certain attack vectors against machines and networks.
Don’t get me wrong: I am not discounting the need, want, or value of a vulnerability assessment. These assessments, as well as pen tests, have their place and need. What I am saying is that these assessments need to be better understood in order to know how and when they should be performed. Additionally, there have been companies that run regular vulnerability assessments and the same vulnerabilities keep coming up every single scan. These companies are either overwhelmed with the amount of vulnerabilities present in their networks and don’t know how to fix them, or they don’t see the value or need in fixing them. Penetration tests can enforce the reasoning. In turn, by better understanding what the difference is, the clients will understand what to expect as a final product and won’t be dissatisfied with the results of each test.
Read more!
Friday, July 23, 2010
Tabnabbing
I was recently interviewed on News Channel 5 about Tabnabbing which is a new technique that can be used for phishing. Tabnabbing is where one of your browser tabs changes, usually without your knowledge, to an attacker controlled website. Usually the website changes to something that looks familiar to the victim like Gmail, Facebook or Twitter. This can usually trick the victim to think that they have been logged out of a website. If the victim enters their credentials into the phishing site they are sent to the attacker. The credentials are then harvested and the victim is forwarded to the legitimate web site.
Check out the video and article over at NewsNet5.com.
Read more!
Check out the video and article over at NewsNet5.com.
Read more!
Thursday, July 22, 2010
Be An Information Security Green Beret
Not so long ago while flipping through channels on the TV I happened upon a documentary of the United States Army’s Special Forces, also known as the “Green Berets.” Never having served myself, my perception of this group was always based more on movies like “Rambo” where the Green Beret is an unstoppable one-man army who takes on the bad guys singlehandedly. In the real world, of course, this turns out not to be the case.
The Green Berets have many different groups and many different missions. And while like Rambo they are expected to have exceptional and specialized combat skills, what was fascinating to me was the focus on “soft skills.” One of their missions is to build insurgent and counter-insurgent groups from whatever groups of people they have available. They need to be able to communicate with natives of foreign countries, train them in the use of weapons and tactics, and lead them into battle. A single 12-man “A-Team” is expected to be capable of building and leading a 200 member guerrilla force! Within the military this is called a “Force Multiplier” and it’s a very powerful concept.
Read more!
Thursday, July 15, 2010
Getting Things Done: Stop Debating Security Minutiae
Many are familiar with David Allen's "Getting Things Done" methodology, used for time management to increase productivity and focus. Do you use it? Ask yourself, "What is the next physical action required to move this project forward?" Repeat this process until everything in the world is finished. It's just that simple.
What are minutiae? Minor details. More importantly, minutiae are minor details of negligible importance.
Negligible importance? Yes, negligible. Meaning, when you're studying something of larger magnitude, the items of negligible importance can be ignored or neglected. That's right, move on, you've got bigger fish to fry.
• We've got to look at better anti-virus software because our current one is not detecting malware X!
• We can't force our clients to change their passwords to our external portal! We'll have an uprising and get a ton of calls!
• Writing policy is a waste of time because employees won't follow the rules!
• Risk management has no place here because we don't even have time to patch all of our systems!
• Don't bring up PCI compliance around the CFO, he won't care.
We love to debate minutiae everywhere, in all facets of life. Information security is no different; it's a beloved exercise because it absolves us from actually having to do anything. And it makes us feel good! It makes us feel satisfied (mmm, tasty tasty minutiae)! But really all we've done is spun our wheels, and failed to persuade or change people’s minds.
Debating minutiae is crippling for a security program. It stunts growth and maturity. When using minutiae to build a security program, it's paralyzing. An organization will lay band-aids on everything that's in front of them; they'll focus only on the trees instead of the forest. They'll only discuss what's comfortable, or what's within their wheelhouse.
Now, move away from your keyboard, settle down, and retract your claws, Mr. Devils-In-The-Details. A wise older man with a tablet recently told me, “One man’s minutiae is another man’s job description.” I'm not saying you should ignore specificity to the point of ambiguousness. You absolutely need details. But really, you need them only at specific times. More often than not, they confuse and delay. They take the focus off of root, systemic issues - that feels good to everyone involved, because then they can talk about the things that are in front of them all day, the things they're experts in (read: comfortable). Do you work for a large organization? How many meetings were you in today that lasted more than an hour? Did you spend the majority of the time in your meetings talking about things that didn't really matter at that point? Most meetings include more trivial details than minor, important details.
You want to get things done? Start big, skim the surface across all areas, bring up uncomfortable security topics, continually assess, and then do something with that information - build a plan, and establish success and failure criteria on what it is you’re trying to get done so that you can clearly separate the minutiae from the bull’s-eye. Once you’ve got the bull’s-eye, create a timeline and go. Important details will flush themselves out. I promise. People who get things done realize this. Call us if you'd like to talk about it.
Read more!
What are minutiae? Minor details. More importantly, minutiae are minor details of negligible importance.
Negligible importance? Yes, negligible. Meaning, when you're studying something of larger magnitude, the items of negligible importance can be ignored or neglected. That's right, move on, you've got bigger fish to fry.
• We've got to look at better anti-virus software because our current one is not detecting malware X!
• We can't force our clients to change their passwords to our external portal! We'll have an uprising and get a ton of calls!
• Writing policy is a waste of time because employees won't follow the rules!
• Risk management has no place here because we don't even have time to patch all of our systems!
• Don't bring up PCI compliance around the CFO, he won't care.
We love to debate minutiae everywhere, in all facets of life. Information security is no different; it's a beloved exercise because it absolves us from actually having to do anything. And it makes us feel good! It makes us feel satisfied (mmm, tasty tasty minutiae)! But really all we've done is spun our wheels, and failed to persuade or change people’s minds.
Debating minutiae is crippling for a security program. It stunts growth and maturity. When using minutiae to build a security program, it's paralyzing. An organization will lay band-aids on everything that's in front of them; they'll focus only on the trees instead of the forest. They'll only discuss what's comfortable, or what's within their wheelhouse.
Now, move away from your keyboard, settle down, and retract your claws, Mr. Devils-In-The-Details. A wise older man with a tablet recently told me, “One man’s minutiae is another man’s job description.” I'm not saying you should ignore specificity to the point of ambiguousness. You absolutely need details. But really, you need them only at specific times. More often than not, they confuse and delay. They take the focus off of root, systemic issues - that feels good to everyone involved, because then they can talk about the things that are in front of them all day, the things they're experts in (read: comfortable). Do you work for a large organization? How many meetings were you in today that lasted more than an hour? Did you spend the majority of the time in your meetings talking about things that didn't really matter at that point? Most meetings include more trivial details than minor, important details.
You want to get things done? Start big, skim the surface across all areas, bring up uncomfortable security topics, continually assess, and then do something with that information - build a plan, and establish success and failure criteria on what it is you’re trying to get done so that you can clearly separate the minutiae from the bull’s-eye. Once you’ve got the bull’s-eye, create a timeline and go. Important details will flush themselves out. I promise. People who get things done realize this. Call us if you'd like to talk about it.
Read more!
Wednesday, July 7, 2010
Trust, But Verify: Full-Time Compliance
You can Google "trust, but verify" and come up with hundreds of articles regarding one of Ronald Reagan's signature catch phrases, accountability, auditing, etc. It can also be considered the default credo of the auditing community. Regardless of where it came from and the potential overuse of the phrase, it's what I live by and is a code that should be followed by anyone responsible for their company's compliance/governance programs and the security of sensitive data. Just about every regulation that deals with the protection of sensitive information requires some form of risk management and/or validation of controls. Proper compliance and risk management programs will not be successful without a high level of verification that proper security controls are in place and operating effectively.
Read more!
Subscribe to:
Posts (Atom)
Posts
