Critical Control 1 - Inventory of Authorized and Unauthorized Devices

Published: 2011-10-03
Last Updated: 2011-10-04 20:01:33 UTC
by Mark Hofman (Version: 1)
1 comment(s)

Control 1

How many servers are in your DMZ?
How many Servers do you have in total?
How many workstations are connected to the network?
How many printers?
Switches/switches/routers/firewalls/Access Points?

If you can answer all the questions above for your organisation accurately, well done. Unfortunately the reality is that many people will not be able to answer them at all.  

Knowing what you have in your environment is critical to the security of the environment. We know that many attackers use automated processes to identify and attack machines on the internet.  If you are not aware of what internet facing systems you have, or they are not controlled, then it is likely that they will be discovered and compromised quickly.  So it is quite important to know what is actually there.

How can you achieve that? you need to be able to control what is plugged in.  Failing that, you will need to know when something has been plugged in.  802.1x controls or other forms of Network Access Control will help you achieve the first, but this may not be suitable for all areas of your environment, or you may not get around to implementing it for a while.

Detecting what is plugged in can be achieved in a number of ways.  Tools like arpwatch will detect when something is plugged in.  You could scan the network segment on a regular basis using something like nmap and use ndiff to compare the results.  This will let you know when something is connected to your network.   You my be able to watch DHCP allocations and detect or prevent unauthorised allocations.  In order for it to be effective you will need some sort of inventory, if you don't know what you have, then you will not know what should or should not be there.  Document the operating systems in use, the types of hardware used, switch types, printer types etc.  

There are of course other tools that will help in this scenario. Many management tools will have inventory capabilities, some patching tools have the capability and some of the AV solutions will now detect "unknown" devices on the network.  

What do you do to identify and control what is on your network?

Mark - Shearwater

1 comment(s)

Beauty and the BEAST

Published: 2011-10-03
Last Updated: 2011-10-03 19:19:25 UTC
by Bojan Zdrnja (Version: 2)
6 comment(s)

(This is a bit longer diary – if you are just interested in conclusion and recommendations, skip below to the “Is SSL broken?” section. I recommend that you read the whole diary – and let us know if you have any comments).

Unless you’ve been hiding on a deserted island, you heard about the latest attack on SSL, named BEAST. We wrote several diaries (first, second, third) on this topic. I got interested into the attack a lot and finally had some time to go through all the details.

So, first of all – big props to Duong and Rizzo for implementing this in practice. While the idea itself is really cool (a bit more about it below), the implementation is what really impressed me, and all the effort they invested into the research here.

Some basics about the attack

As has been already written on million places, the BEAST attack attacks SSL 3.0 and TLS 1.0, in particular their implementation  of the Cipher-block chaining (CBC) block encryption algorithms.

This is probably the most widely used mode for block encryption algorithms today, so it is obvious that any attack on this (and SSL/TLS overall) can have huge impact.

In a nutshell, BEAST very cleverly uses predictable IV (initialization vector) values in order to set up particular input vales for SSL. By very carefully modifying these input values, the attacker can exploit BEAST to guess what value 1 byte in an encrypted block had. Block encryption algorithms fragment input messages into blocks, usually 8 or 16 bytes long.

The IV is initially a random number and then every next block uses the previous cipher text as the IV. The IV is XORed with the input plain text – this produces input for the encryption algorithm. So normally, in a block encryption algorithm, encrypted block C4 = encryption ( C3 XOR P4), where C is an encrypted block and P is a plain text block.

According to this, the last blocks (CN) IV will be CN-1: CN = encryption (CN-1 XOR PN). Doung and Rizzo cleverly used this so they leave the channel open and add the next block (N+1) whose content will be of one of the previous blocks. Imagine that we supply P4 (with only 1 byte modified), XORed with CN and it’s original C3:

CN+1 = encryption ( CN XOR ( CN XOR C3 XOR P4 ))

This results in:

CN+1 = encryption ( C3 XOR P4)

For which we know the result as it is C4! Now, if we can influence P4 to give us the opportunity of guessing one byte (by supplying, for example, 7 known bytes) we can try to guess what the last byte was: if CN+1 is equal C4, we guessed the byte, otherwise we didn’t.

This is just a brief overview – for more information read the leaked paper – it is written very well.

Guessing HTTP values

As you’ve seen above, the attacker can now guess byte by byte. With HTTP creating this boundary is actually simple since we know what each HTTP request will look like:

GET /AAAAA HTTP/1.1<cr><lf>
header

If we want to guess the first character of Header, we can make the previous line 23 bytes long (if blocks are 8 bytes each):

GET /AAAAAAA HTTP/1.1<cr><lf>H

Notice how only H will make it into the 3rd block. The attacker now knows the content of the first two blocks and can try to guess the first character by using the attack described above.

Attack prerequisites and implementation

As if the attack itself was not impressive enough, Doung and Rizzo managed to actually do all this in the browser. Let us revisit what they have to do for this attack:

  1. They need to pull a MITM attack on the victim. This is needed for two things: first, they need to monitor the network traffic in order to guess bytes. Second, they need to somehow influence the browser to make it issue requests such as the one shown above that will let them do the guessing. For the demo they used a Java applet, but there are other ways of exploiting this (more below).
     
  2. Once they injected the Java applet into the victim’s browser, they wait for the victim to log in to the target site. Now the Java applet will open an SSL connection to the target site and send a specially crafted request as above (i.e. GET /AAAAAAA …). The SSL connection must stay opened so they can feed new blocks in real time, as they monitor network traffic. This will allow them to guess content of bytes encrypted by the browser. So, their Oracle in this case is the browser itself – the web server that they are attacking is irrelevant, it is the victim’s browser that let’s them guess encrypted content.

As you can see from 2), the crucial requirement is that the SSL connection is open (so they are able to append the data and use the last block as the IV). This proved to be very difficult to do (and is one of the things in Doung’s and Rizzo’s research that impressed me the most).

There are many ways that can be used in a browser to open a new connection. The easiest way is to use JavaScript’s XmlHttpRequest (XHR). There are some limitations here though. First, Internet Explorer does not support XmlHttpRequest level 2 (which is needed in order to send cookies) and instead has an XDomainRequest object. XDomainRequest will never send cookies so, in theory, Internet Explorer users are more protected than Mozilla Firefox or Chrome users (is this a first or what!?!).

Firefox and Chrome support XHR level 2. It is worth pointing out here that the attacker is not able to read the request response through active scripting due to the fact that the server will not set the correct Access-Control-Allow-Origin header, but the attacker does not care about that since he just wants to be able to use the browser as an Oracle for guessing encrypted stuff. Similarly, settings such as Secure or HttpOnly will not help with this attack (but will with other).

The biggest problem with this is, it appears, that XHR cannot be used to create streaming requests, which are needed to perform the guessing (the attacker needs to be able to append those pre-calculated blocks to a request). Many other possible exploitation vectors, such as plain IFRAMEs, Websockets or Silverlight have similar issues that prevented Doung and Rizzo from using them – keep in mind that this does not mean these are “safe” against BEAST, just that current attempts to use them failed.

Is SSL broken?

Simple question, simple answer – NO. As you can see above, there are many prerequisites that the attacker needs to do in order to conduct the BEAST attack.

While the attack is inherent to block encryption algorithms, it requires the attacker to be able to append these specially crafted input blocks into an active session. In other words, it is very difficult, or impossible to exploit BEAST on other protocols that use SSL, such as POP3s, IMAPs and similar. Doung and Rizzo did it with browsers because there are many scripting (extending) possibilities with browsers and the HTTP protocol.

Couple of things I would suggest doing:
-    Be careful about switching to TLS 1.1 or TLS 1.2 because you might break things for many clients. While this definitely fixes the vulnerability, be very careful.

-    Move to RC4 over CBC. RC4 has also its own issues but just the fact that Google prefers RC4 says something too – you can use the nice sslscan utility to see what ciphers are supported by a server, here are the results for mail.google.com:
# sslscan --no-failed mail.google.com:443
                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  Version 1.8.2
             http://www.titania.co.uk
        Copyright Ian Ventura-Whiting 2009

Testing SSL server mail.google.com on port 443

  Supported Server Cipher(s):
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):
    SSLv3  128 bits  RC4-SHA
    TLSv1  128 bits  RC4-SHA

-    Do not accept any unsigned Java applets and allow them to run. You should always do this, not only in this case. Same goes for any other active technology.

-    When accessing sensitive sites, close all browser windows (not tabs, all windows) and open a fresh new one and use it only to access the sensitive site. After you’re done, close it again and reopen it for further surfing. This should make exploitation a bit difficult, but keep in mind that as of Java 6 Update 10 an attacker can potentially trick a victim into dragging applets out of browser windows so they continue running after the browser is closed (I’m not sure if this can be used to help BEAST).

-    If you are a sensitive server owner – keep an eye on errors on your server. The BEAST attack needs to issue quite a bit of requests (generally each byte has a 1/256 chance of being guessed, so in average 128 blocks need to be appended to a single request). One request is needed for a byte so if you see a lot of 404 requests with similar patterns (/AAAAA) that should raise some flags. Of course, you should always monitor and correlate your logs, not only now :)

At the end, I must again admit I like the attack a lot - the idea is really cool, amazing how they came up with everything. That being said, as you can see above, there are a lot of prerequisites for successful exploitation so I don't think that the resulting risk is very high at the moment.

(small update): There have been some comments about recommending RC4. While there have been plenty of bad/broken/failed implementations of RC4 (take a look at WEP), I definitely do not consider RC4 to be broken, especially not the OpenSSL implementation that is widely used.

Besides me ;-), US CERT is also recommending that RC4 is prioritized in their advisory available at http://www.kb.cert.org/vuls/id/864643.

--
Bojan
INFIGO IS
@bojanz on Twitter

Keywords: beast ssl
6 comment(s)

Security 101 : Security Basics in 140 Characters Or Less

Published: 2011-10-03
Last Updated: 2011-10-03 16:00:03 UTC
by Tom Liston (Version: 1)
4 comment(s)

It was one of THOSE gigs: an internal penetration test against a client that, considering the amount of personal information they held on their customers, should have been well prepared.  And yet, we went from "you-can-plug-your-laptop-in-over-there" to "Domain Admin" in... well, let's just say a "shockingly small" number of hours.  And it just went downhill from there...

For me, writing up the resulting report, triggered what I could only describe as a "crisis of faith." While, as a security community, I don't fool myself that we have it all "figured out," I had – up until now – strongly believed that we were making progress.  And yet, I had just spent a week immersed in a corporate culture that seemed to have focused itself on so many higher-level security issues that the basics – the "Security 101" stuff – was just plain overlooked.

The more I thought about it, the more it bothered me.  It wasn't some fancy-schmancy 'leet h@x0r 0-day that let us take down this organization from the inside: it was stupid-simple low-hanging fruit.  I spent a bit of time chatting over Twitter with the ever-insightful Brian Honan (@BrianHonan) and came to the conclusion that the security community may have reached an awkward age at which we're grown up enough to be focusing on the golly-gee/whiz-bang/cool stuff (vis-à-vis the "APTification" of all that passes for security discussion) and, as a result, we're neglecting the basic, "Security 101" stuff that raised the bar in the first place.

Think about it: Over the past year, how many high-profile hacks have been the result of awesome cutting edge skillz?  How many have happened because someone just flat-out did something dumb?  Take a quick gander at back issues of SANS NewsBites and I think you'll be convinced as well: We truly are neglecting the basics.

Since October is "Security Awareness Month," a few weeks back, I sent out a call on Twitter for folks to submit pithy, 140 character-long, chunks of Security 101 wisdom.  Below, I've compiled together the resulting list, along with the Twitter name of the submitter.

If you're feeling a little shaky on your security knowledge, then heeding this advice might just save your behind.  Even if you're confident that you "know it all," a quick review might have you discovering stuff you've inadvertently overlooked.  Either way, I heartily recommend that you read (and heed) this advice.  Also, if something particularly strikes your fancy, you might consider following the author on Twitter... you never know – you might learn even more.

One last "housekeeping" note: I lightly edited these to remove some of the more blatant "Twitterisms" used to stuff big thoughts into limited character lengths.  If anything got messed up, I'll take the blame.

@ChrisJohnRiley If you can guess where PHPmyAdmin is installed, then so can attackers.
@DavidJBianco You are already pwn3d. The question is, "What will you do about it?"
@Keldr1n Don't leave default passwords on the administrative interfaces of your 3rd party web applications.
@Keldr1n Know your network - and all devices in it - well enough to spot unusual activity.
@Keldr1n Users are almost always the weakest link. Make it a priority to educate them. Do most of yours even know what phishing is?
@averagesecguy Security 101: If you don't need it, turn it off.
@bowlesmatt Passphrases are the new passwords. Make a sentence that is long, hard to guess, and easy to remember. ihatepasswordsseewhatididthere?
@bowlesmatt Patch your systems and disable any unused services to reduce attack surface.
@bradshoop Never trust a host you can't trust.
@bradshoop Computers remember a lot. Even more if you contact security personnel before you reboot.
@bradshoop Dedicate personnel to prevention AND detection. Preferably the same personnel in rotation to breed familiarity and contempt.
@connellyuni It's more important to know what you don't know than it is to know what you do know.
@cutaway Try to avoid saying "We are investigating... why equipment that we have a destruction certificate for was... sold online" to the media.
@cutaway Assets using secure authentication are directly and adversely impacted by your assets using plain text authentication.
@cutaway Complacency: 1) Self-satisfaction especially when accompanied by unawareness of actual dangers or deficiencies. 2) You will be hacked.
@cutaway Default SSL Certs for internal management interfaces should be replaced with valid certificates associated with the organization.
@cutaway Don't be afraid of your incident response plan. Conducting investigations will give your team experience and eventually reduce costs.
@cutaway How do you "Find Evil" in your organization? Seriously, go "Find Evil" and report back to me.
@cutaway IT environments are complex systems. They require a System Development Life Cycle to effectively manage AND secure.
@cutaway If your product allows remote connections somebody WILL write a python/perl/ruby script to connect to it and send whatever THEY want.
@cutaway Monitor and alert to new accounts and accounts being added to Domain Administrator, SUDO, or root groups.
@cutaway Product certification does not mean it has been deployed correctly. Review placement, logging, access, input validation, etc...
@cutaway Service accounts should adhere to corporate password policies and be monitored for modifications including lockout.
@eternalsecurity Make sure you're protecting the right thing. A belt AND suspenders doesn't help if you're not wearing pants.
@hal_pomeranz "A backup is not a backup until you do a restore." #sysadminkoan
@hy2jinx Attack vectors and regulatory requirements change. "That's how we've always done it" is a poor and lazy excuse.
@hy2jinx Scanner "infos" can turn up bigger issues than you'd guess. Look at overall results, not just singles.
@hy2jinx Five missing patches across 100 devices does not equal "five vulnerabilities."
@hy2jinx It's cheaper to consult a security professional from conception than mere days before "go live."
@hy2jinx Security professionals should be empowered to point the business towards good decisions and reserve the power of "No" for a last resort.
@itinsecurity In your encryption system, your key is the weakest link. If it isn't, you're doing it wrong.
@itinsecurity Security is not a box you buy or an app you write. It's an emergent property, a sum greater than its parts.
@jarocki "Dear User: Millions of $$ of software won't keep you from clicking that link. Only YOU can prevent link clicking."
@jarocki When it comes to security controls, Trust But Verify... nah, forget the Trust... just Verify.
@jimmyzatl If you don't log "accepts" in your FW logs for admin protocols you will have no way of knowing when those accounts are abused.
@jimmyzatl An encryption algorithm that has to be hid from the public is by definition a weak algorithm...
@ken5m1th That successful PCI DSS Report On Compliance will not save you from Zombies.
@kentonsmith When setting up any new system, Step 1: Change default admin password.
@kill9core Security through obscurity, or the practice of hiding flaws hoping they won't be found, has proven time and time again not to work.
@mattdoterasmus Just because your security teams work from 9-5, doesn't mean attackers aren't looking the rest of the time.
@omegadefence The attitude that "it won't or can't happen to us" because "we're too small/big/have nothing to offer" is dangerous.
@omegadefence The attitude that "I can't do anything about it so I won't even bother with security or reporting" is also dangerous.
@omegadefence Analyse your logs in detail, it is those with their heads buried in your logs that hold the key to prevent, detect and recover.
@omegadefence Give only the permissions required to do the normal daily duties, nothing more. Special logons for special occasions.
@omegadefence Best: using high-speed trend analysis with custom searches as well as automated reporting AND followup.
@rob_bainbridge Security teams that work in isolation and without transparency will fail. Collaborate with other risk mgmt - audit, ops risk, etc...
@tccroninv Those that store passwords in plain-text invite catastrophe.
@tliston "We can't implement strong passwords/two-factor authentication. Our users aren't capable," says more about your competence than theirs.
@tliston Developers: Never roll your own encryption, authentication or session management schemes. You're not that smart. Trust me.
@tliston If you don't have written authorization to perform security-type testing in your organization, don't. You're too pretty for prison.
@tliston If you're not putting as much thought into your outbound firewall rules as you are for your inbound rules, you're doing it wrong.
@tliston If you're not supporting a legacy Windows OS, for the love of all that is Holy, turn off LANMAN hashes.
@tliston If you've never tested restoring from your backups, then you don't have backups - you have a crapload of data and hope.
@tliston If your internal security posture is based on,"our employees wouldn't know how to do that," then you're likely already 0wned.
@tliston Remember: As an attacker, I exploit misplaced trust. There's nothing mystical or magical about it.
@tliston Run scans against your network. It's the only way to really know what's out there. I've yet to see a fully accurate network diagram.
@tliston Sanity check security spending. A $500 lock on a cheap wood door doesn't buy security. It just gives a thief something to laugh at.
@tliston Security isn't just about preventing compromise. It's about maintaining confidentiality, integrity & availability despite compromise.
@tliston Security-through-obscurity doesn't work against anything with intelligence, but there's lots of dumb sh*t out on the 'net.
@tliston Taking nude photos of yourself? Don't store them on an always-connected device with little-to-no security. #forscarlett
@tliston Teach your users not to click on unknown links. DON'T send links to your users in email. More info: http://t.co/bdNTRI3O
@tliston Web developers: Give the exact same answer whether you're given a bogus username or password on logins. EXACT. SAME. ANSWER.
@tliston WebApp Devs: Just because you have a <SELECT> with A, B, C, & D as options doesn't mean you'll only ever get A, B, C, or D back.
@tliston Webhosting Companies: Web servers shouldn't be making many *outbound* connections. TCPDump is your friend.
@tliston Your organization's AUP should explicitly prohibit Copyright abuse. You do HAVE an Acceptable Use Policy, right?
@tliston Centralize your logging - you have no idea how helpful it will be.
@tliston Companies who use the same Windows Local Admin password on large numbers of machines are ripe for picking by malicious insiders
@tliston Developers: Input, even data you think you control, can never be trusted. Consider all input a threat and process accordingly.
@tliston Diligent change management practices have saved more asses than a Beverly Hills plastic surgeon.
@tliston Ensure that user accounts are disabled as part of your termination process. Audit all accounts at least semi-annually for "misses."
@tliston High privilege level accounts should be used only for administrative functions, not for day-to-day activities.
@tliston High privilege level accounts should have kick-ass passwords or two factor authentication. Or both.
@tliston If at all possible, disable password authentication for SSH. SSH is a huge brute force target. Keys are your friend.
@tliston If it plugs into your network, know why. The last thing you ever want to hear an admin say is, "That thing has a web interface?!?"
@tliston Learn how to manipulate text files. Learn how to use sed, cut, wc, and grep as a minimum. Text is your friend.
@tliston Logging authentication failures is NOT enough. Log successes and failures.
@tliston Mr. CxO: Your employees are not a "family." Some are untrustworthy. FYI: Some of the people in your real family are pretty sketchy too.
@tliston Never rely on the fact that you "own" anything: data, a communication path, etc... If you do - I 0wn it, I 0wn you. Trust nothing.
@tliston Nothing is more important to the long-term survivability of your organization than a fully functional backup process.
@tliston Packets to or from RFC-1918 addresses should not be allowed to traverse your border firewall in either direction.
@tliston Passwords are no longer security measures. They are merely speed-bumps. Treat them accordingly.
@tliston Physical access trumps most security measures.
@tliston Remember to always think in terms of "defense in depth." A belt AND suspenders is always better than a belt OR suspenders.
@tliston Shared accounts are never a good idea.
@tliston Telnet, FTP, and any other clear-text protocol developed in simpler, more naive times has no business on a modern network.
@tliston There is no excuse - NONE - not to use full disk encryption on laptops. Data breaches due to lost/stolen laptops are inexcusable.
@tliston Unencrypted WiFi is never secure. WEP = Unencrypted WiFi. Trust me. Stop using it. Now. Really.
@tliston Web Developers: Remove comments from your production website code. They serve NO purpose and can give away too much info.
@vaudajordan Total loss of Sony Breach $171M, I wonder how many salaries, code reviews, software, hardware that could have bought.
@zanis1 Assign only those privileges that are required to do the job.

Also, I want to extend a great big "thank you" to all of the people who submitted these tweets using the #sec101 hash tag.  I tried really hard to grab them all... If I missed anyone, I apologize.

Tom Liston
Senior Security Consultant, InGuardians, Inc.
Handler: SANS ISC

Note: Matt (@0xznb) has kindly made a fortune-mod zip file available here of the #sec101 wisdom.

 

4 comment(s)

What are the 20 Critical Controls?

Published: 2011-10-03
Last Updated: 2011-10-03 12:24:31 UTC
by Mark Baggett (Version: 1)
0 comment(s)

[the following is a guest diary contributed by Dr. Eric Cole]

One of the questions I often receive is what are the twenty critical controls.  Details can be found at www.sans.org/cag but the general approach of the controls is to begin the process of establishing the prioritized baseline of information security measures and controls that will lead to effective security. The consensus effort that has produced the controls have identified 20 specific technical security controls that are viewed as effective at defending against the most common methods of attack. Fifteen of these controls can be monitored, at least in part, automatically and continuously. The consensus effort has also identified a second set of five controls that are essential but that are more difficult to be monitored continuously or automatically with current technology and practices; however they are critical to achieving an optimal level of security. Each of the 20 control areas includes multiple individual sub-controls, each specifying actions an organization can take to help improve its defenses.

Additionally, the controls are designed to support agencies and organizations that currently have different levels of information security capabilities.  To help organizations focus on achieving a sound baseline of security and then improve beyond that baseline, certain subcontrols have been categorized as follows:

  • Quick Wins: These fundamental aspects of information security can help an organization rapidly improve its security stance generally without major procedural, architectural, or technical changes to its environment.  It should be noted, however, that a Quick Win does not necessarily mean that these subcontrols provide comprehensive protection against the most critical attacks.  If they did provide such protection, there would be no need for any other type of subcontrol.  The intent of identifying Quick Win areas is to highlight where security can be improved rapidly. 
  • Improved Visibility and Attribution: These subcontrols focus on improving the process, architecture, and technical capabilities of organizations so that the organization can monitor their networks and computer systems, gaining better visibility into their IT operations.  Attribution is associated with determining which computer systems, and potentially which users, are generating specific events.  Such improved visibility and attribution support organizations in detecting attack attempts, locating the points of entry for successful attacks, identifying already-compromised machines, interrupting infiltrated attackers' activities, and gaining information about the sources of an attack.  In other words, these controls help to increase an organization’s situational awareness of their environment. 
  • Hardened Configuration and Improved Information Security Hygiene: These aspects of various controls are designed to improve the information security stance of an organization by reducing the number and magnitude of potential security vulnerabilities as well as improving the operations of networked computer systems.  This type of control focuses on protecting against poor security practices by system administrators and end users that could give an adversary an advantage in attacking target systems.  Control guidelines in this category are formulated with the understanding that a well-managed network is typically a much harder target for computer attackers to exploit.
  • Advanced: These items are designed to further improve the security of an organization beyond the other three categories. Organizations already following all of the other controls should focus on this category.   

For additional details on the controls, please go to www.sans.org/cag.  Portions of the above are taken from version 2.0 of The Twenty Critical Controls. 

----------------
Dr. Eric Cole
twitter: drericcole
école .at. secure-anchor.com

 

0 comment(s)

Comments


Diary Archives