CYBR650 Wrap Up
Hard to believe the semester is over...seems like we just started a couple of weeks ago.
Anyway, here are my final thoughts about the course and final presentation.
This was a pretty cool experience taking the Harry & Mae's Inc. case study through the security inspection week-by-week. At the very beginning, I was looking at things the wrong way. I was looking for particular vulnerabilities, i.e. CVEs, etc. as opposed to looking at the general security posture of the company. This in-turn changed my sources for threat data. I went from the CVE type providers to NIST and DISA references.
The most challenging part of the course was trying to come up with good formats for the deliverables. I had great difficulty coming up with the format I wanted for the threat analysis. The final presentation was also very challenging when it came time to come up with a format. There are varying opinions as to how to make PowerPoint presentations. I have always used bullets on the slides so you don't let the slides take over the presentation, or kill your audience with the amount of data on the slides (death by PowerPoint).
All-in-all it was a rewarding experience that may even pay off on the job.
Friday, May 31, 2013
Sunday, May 19, 2013
Harry & Mae's Action Plan
I think the hardest part of this assignment was actually coming up with the formatting for both the Action Plan and the Final Presentation. After almost two-weeks of work on the action plan, I'm still not 100% content with my format selection. But, after a while, I had to let that go and just get it done.
The formatting for the Final Presentation was not quite so difficult to select, but it was still a bit of a challenge.
Finding specific references for what I knew were findings was also very challenging to say the least. Of particular note along this line was finding a reference for passwords--password complexity, history, minimum and maximum lifetimes, etc. The best reference I could come up with was NIST Special Publication 800-53, "Recommended Security Controls for Federal Information Systems
I think the hardest part of this assignment was actually coming up with the formatting for both the Action Plan and the Final Presentation. After almost two-weeks of work on the action plan, I'm still not 100% content with my format selection. But, after a while, I had to let that go and just get it done.
The formatting for the Final Presentation was not quite so difficult to select, but it was still a bit of a challenge.
Finding specific references for what I knew were findings was also very challenging to say the least. Of particular note along this line was finding a reference for passwords--password complexity, history, minimum and maximum lifetimes, etc. The best reference I could come up with was NIST Special Publication 800-53, "Recommended Security Controls for Federal Information Systems
and Organizations". Appendix F, the Security Control Catalog had a reference for passwords. Although, it states the organization sets the standards as far as complexity, history, etc.
For this project, all my references ended up coming from NIST and DISA. Again, DISA is part of the DoD, but their security checklists can easily be applied to any organization.
For this project, all my references ended up coming from NIST and DISA. Again, DISA is part of the DoD, but their security checklists can easily be applied to any organization.
Sunday, May 12, 2013
Security Checklists
I am a US government civilian IT Specialist. Part of my job is to run security checks on the equipment my shop maintains. Our guidance for running these checks is a series of Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency (DISA). We commonly refer to these checklists as DISA STIGs. For what it's worth, I use the DISA DNS STIG almost daily in my work.
These checklists are provided for almost every IT application and system you could imagine. Here is a link to the "master list" of the checklists:
http://iase.disa.mil/stigs/a-z.html
These checklists are not simply run down the list and check a box for each item. They are arranged as specific checks with something to check, an explanation as to why the item is of concern, information about applicability (version info, etc.) and a severity level for the finding if it is not compliant. Normally, there is also a recommended fix action for each item. The finding categories are ranked as follows and described using the DISA explanations for the severity levels:
CAT I (highest severity) - "Any vulnerability, the exploitation of which will, directly and immediately result in loss of Confidentiality, Availability, or Integrity. An ATO will not be granted while CAT I weaknesses are present." (DISA, 2012)
Cat II (medium severity) - "Any vulnerability, the exploitation of which has a potential to result in loss of Confidentiality, Availability, or Integrity. CAT II findings that have been satisfactorily
mitigated will not prevent an ATO from being granted." (DISA, 2012)
CAT III (lowest severity) - "Any vulnerability, the existence of which degrades measures to protect against loss of Confidentiality, Availability, or Integrity. Assigned findings that may impact IA
posture but are not required to be mitigated or corrected in order for an ATO to be granted." (DISA, 2012)
I should further explain that ATO stands for Authorization to Operate, i.e. allowing the system/application to be placed into production. So, as it says above, CAT I and CAT II findings must be mitigated in order for a system to be granted an ATO.
Sources:
DISA. Defense Information Systems Agency, (2012). Network infrastructure technology overview
version 8, release 5
I am a US government civilian IT Specialist. Part of my job is to run security checks on the equipment my shop maintains. Our guidance for running these checks is a series of Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency (DISA). We commonly refer to these checklists as DISA STIGs. For what it's worth, I use the DISA DNS STIG almost daily in my work.
These checklists are provided for almost every IT application and system you could imagine. Here is a link to the "master list" of the checklists:
http://iase.disa.mil/stigs/a-z.html
These checklists are not simply run down the list and check a box for each item. They are arranged as specific checks with something to check, an explanation as to why the item is of concern, information about applicability (version info, etc.) and a severity level for the finding if it is not compliant. Normally, there is also a recommended fix action for each item. The finding categories are ranked as follows and described using the DISA explanations for the severity levels:
CAT I (highest severity) - "Any vulnerability, the exploitation of which will, directly and immediately result in loss of Confidentiality, Availability, or Integrity. An ATO will not be granted while CAT I weaknesses are present." (DISA, 2012)
Cat II (medium severity) - "Any vulnerability, the exploitation of which has a potential to result in loss of Confidentiality, Availability, or Integrity. CAT II findings that have been satisfactorily
mitigated will not prevent an ATO from being granted." (DISA, 2012)
CAT III (lowest severity) - "Any vulnerability, the existence of which degrades measures to protect against loss of Confidentiality, Availability, or Integrity. Assigned findings that may impact IA
posture but are not required to be mitigated or corrected in order for an ATO to be granted." (DISA, 2012)
I should further explain that ATO stands for Authorization to Operate, i.e. allowing the system/application to be placed into production. So, as it says above, CAT I and CAT II findings must be mitigated in order for a system to be granted an ATO.
Here is an example to CAT I findings in the DISA Network Policy Security Technical
Implementation Guide, Version: 8 Rrelease 14:
ISP connections exist without approval.
No deep packet inspection- must use firewall/proxy device with deep packet inspection enabled.
Deny by default policy not implemented - for a firewall and/or perimeter router.
Unencrypted passwords stored offline.
These are just a few of the CAT I items.
So, clearly these checklists were developed by the military, but they are unclassified and readily available for anyone to download and use. I contend they would be a fantastic reference for any organization to use.
Sources:
DISA. Defense Information Systems Agency, (2012). Network infrastructure technology overview
version 8, release 5
DISA. Defense Information Systems Agency, (2013). Network policy security technical implementation guide version: 8 release 14
Sunday, May 5, 2013
NIST Special Publications
I have found the NIST series of Special Publications to be an invaluable source of information both for in class work and on the job. As far as on the job references go relating to my duties as a DNS administrator, SP 800-81, Rev 1 ranks at the top of my go to how to guides. It was a huge help when I had to implement DNSSEC on the DNS zones I administer. I had previous in class training on DNSSEC, but it was 3 years prior to when I actually had to implement DNSSEC.
That said, NIST publishes a plethora of guides for any type of IT-related matter you may encounter, be it an in class or "real world" type environment. Check out this link to see the full list of NIST Special Publications:
http://csrc.nist.gov/publications/PubsSPs.html
Of particular note this week would be SP 800-30, Rev 1 "Information Security", which is a guide to conducting risk assessments:
http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf
That's all for this week...cheers!
I have found the NIST series of Special Publications to be an invaluable source of information both for in class work and on the job. As far as on the job references go relating to my duties as a DNS administrator, SP 800-81, Rev 1 ranks at the top of my go to how to guides. It was a huge help when I had to implement DNSSEC on the DNS zones I administer. I had previous in class training on DNSSEC, but it was 3 years prior to when I actually had to implement DNSSEC.
That said, NIST publishes a plethora of guides for any type of IT-related matter you may encounter, be it an in class or "real world" type environment. Check out this link to see the full list of NIST Special Publications:
http://csrc.nist.gov/publications/PubsSPs.html
Of particular note this week would be SP 800-30, Rev 1 "Information Security", which is a guide to conducting risk assessments:
http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf
That's all for this week...cheers!
Sunday, April 28, 2013
So, now for something completely different...
One of the main duties I carry out at my place of employment is being the "DNS guy". So that said, I had to relay the information I located about "DNS Amplification Attacks" I found this week.
This attack relies on the use of public recursive DNS servers. These are servers that anyone may point to in order to perform recursive DNS lookups. Many ISPs maintain these open type of servers.
This attack results in a distributed denial of service (DDOS) attack against a target system. The attacker sends DNS requests to the DNS server with the forged IP address of the target system. The target is then buried by a flood of DNS replies from the DNS server used as the attack vector. DNS replies are usually larger than the requests, so the target is indeed buried in traffic. DNS traffic is almost always permitted, so this type of attack is hard to detect.
There is little the target can do to defend itself unfortunately. There are however a few things DNS administrators can do to prevent their servers becoming attack vectors:
1. Limit recursive queries to those systems the server should handle lookups for. So, if you are using Cox Communications, they should limit queries to Cox Communications IP addresses.
2. Disable recursion on authoritative DNS servers. Authoritative servers should only answer queries, not make them.
3. This was news to me, but apparently there is an experimental response rate-limiting capability in BIND 9. It was created to lessen the possibility of these attacks. Unfortunately, Windows DNS does not have this feature. (I wonder how many Windows DNS servers are public servers??? I wouldn't do it.)
Here is a link to the US-CERT alert:
http://www.us-cert.gov/ncas/alerts/TA13-088A
That's it for this week--cheers!
One of the main duties I carry out at my place of employment is being the "DNS guy". So that said, I had to relay the information I located about "DNS Amplification Attacks" I found this week.
This attack relies on the use of public recursive DNS servers. These are servers that anyone may point to in order to perform recursive DNS lookups. Many ISPs maintain these open type of servers.
This attack results in a distributed denial of service (DDOS) attack against a target system. The attacker sends DNS requests to the DNS server with the forged IP address of the target system. The target is then buried by a flood of DNS replies from the DNS server used as the attack vector. DNS replies are usually larger than the requests, so the target is indeed buried in traffic. DNS traffic is almost always permitted, so this type of attack is hard to detect.
There is little the target can do to defend itself unfortunately. There are however a few things DNS administrators can do to prevent their servers becoming attack vectors:
1. Limit recursive queries to those systems the server should handle lookups for. So, if you are using Cox Communications, they should limit queries to Cox Communications IP addresses.
2. Disable recursion on authoritative DNS servers. Authoritative servers should only answer queries, not make them.
3. This was news to me, but apparently there is an experimental response rate-limiting capability in BIND 9. It was created to lessen the possibility of these attacks. Unfortunately, Windows DNS does not have this feature. (I wonder how many Windows DNS servers are public servers??? I wouldn't do it.)
Here is a link to the US-CERT alert:
http://www.us-cert.gov/ncas/alerts/TA13-088A
That's it for this week--cheers!
Sunday, April 21, 2013
Sources of Vulnerabilities
For this week, I have studied my earlier references and chosen Symantec and USCERT as the best. I have to admit, I haven't scoured the Web for other sources but these seem to be the best I have come across so far. As I progress further in this effort, I may find others. I will keep you posted if I find others...
For this week, I have studied my earlier references and chosen Symantec and USCERT as the best. I have to admit, I haven't scoured the Web for other sources but these seem to be the best I have come across so far. As I progress further in this effort, I may find others. I will keep you posted if I find others...
Sunday, April 14, 2013
Harry & Mae's
This week, I'll discuss some aspects of the Harry & Mae's case study that I noted.
First off, I was concerned with Tom Pierce's attitude about security in his organization. After a data breach affecting 25,000 customers credit data, I'd like to think he'd be very concerned about tightening IT security.
Case in point, the password policy--or should I say lack thereof. The very lax policy was pushed from the top down by Mr. Pierce. We will definitely have to tread carefully here and let Mr. Pierce know that there must be a strong password policy put in place and endorsed by senior leadership in the organization. It would be very easy for an insider with bad intentions to find a password near a user's PC, login, and start doing their dirty work.
I am also concerned about the employment of the security appliances used by Harry & Mae's. Mr. Pierce seems to think they are not working. I think he does not really know that they are actually not being used properly. Examples of this are the Sonic Wall firewalls allowing all traffic through and the Barracuda Spam & Firewall appliances running without activated subscriptions. This area will also call for a frank discussion with Mr. Pierce.
Also of concern is the same Web server hosting both internal and external data. This is definitely not a good decision. The internal and external data should be managed by separate servers.
Lastly, something must be done to protect the point-of-sale systems. They must be locked down to prevent casual web surfing by employees.
My biggest assumption with this case is that Mr. Pierce has Harry & Mae's best interests at heart and will see the reason in tightening IT security in his organization. Another data breach could spell the end of Harry & Mae's!
This week, I'll discuss some aspects of the Harry & Mae's case study that I noted.
First off, I was concerned with Tom Pierce's attitude about security in his organization. After a data breach affecting 25,000 customers credit data, I'd like to think he'd be very concerned about tightening IT security.
Case in point, the password policy--or should I say lack thereof. The very lax policy was pushed from the top down by Mr. Pierce. We will definitely have to tread carefully here and let Mr. Pierce know that there must be a strong password policy put in place and endorsed by senior leadership in the organization. It would be very easy for an insider with bad intentions to find a password near a user's PC, login, and start doing their dirty work.
I am also concerned about the employment of the security appliances used by Harry & Mae's. Mr. Pierce seems to think they are not working. I think he does not really know that they are actually not being used properly. Examples of this are the Sonic Wall firewalls allowing all traffic through and the Barracuda Spam & Firewall appliances running without activated subscriptions. This area will also call for a frank discussion with Mr. Pierce.
Also of concern is the same Web server hosting both internal and external data. This is definitely not a good decision. The internal and external data should be managed by separate servers.
Lastly, something must be done to protect the point-of-sale systems. They must be locked down to prevent casual web surfing by employees.
My biggest assumption with this case is that Mr. Pierce has Harry & Mae's best interests at heart and will see the reason in tightening IT security in his organization. Another data breach could spell the end of Harry & Mae's!
Subscribe to:
Posts (Atom)