Yesterday’s TRISC event had some great talks. The morning talks were good and were higher-level keynotes that, to be honest, I didn’t take good notes on. The talk on legal implications for the IT industry was really interesting. I was able to talk with Dr. Gavin Manes (a fellow Oklahoman) about legal implications of cloud computing and shared compute resources. In the old days, a lawyer was able to get physical access to the box and use it as evidence but it sounds like with the growth of SaaS that the courts don’t expect have to have physical box access but the law seems to be 5 to 10 yrs behind on this and it could backfire on us.
The three classes I attended in the afternoon are added below. Some of the notes are only partially complete, so take it for what it is: notes. Interspersed with the notes are my comments, but unlike my astute colleague Ernest, I didn’t delineate my comments with italics. So, pre-apology to any speakers if they feel like I am putting words there that they didnt say. If there are any incorrect statements, please feel free to leave a comment and I will get it fixed up, but hopefully I captured the sessions in spirit.
Breaking down the Enterprise Security Assessment by Michael Farnum
Michael Farnum did a great job with this session. If you want to follow him on twitter, his id is @m1a1vet and he blogs over at infosecplace.com/blog.
External Assessments are crucial for compliance and really for just actual security. We can’t be all about compliance only. One of the main premises of the talk is to avoid assumptions. Ways to do that in the following categories are below.
In Information Gathering check for nodes even if you think they don’t exist:
- Web Servers. Everything has a web server nowadays. Router, check. Switch, check. Fridge, check.
- Web Applications and URLs
- Web app with static content (could be vulnerable even if you have a dummy http server). Might have apps installed that you didn’t even know (mod_php)
- Other infrastructure nodes. Sometimes we assume what we have in the infrastructure… Don’t do that
In addition to regular testing, we need to remember wireless and how it is configured. Most companies have a open wireless network that goes just to the internet. The question that needs to be addressed in an assessment is: is it really segmented? For this reason we need to make sure that wireless has an IDS tied to it.
Basic steps of any assessments are identification and penetration. We don’t need to always penetrate if we have the knowledge of what we are doing but we do need to make sure that we identify properly. No use in penetrating if you can show that the wireless node allows WEP or your shopping cart allows non-https.
Culture issues are also something that we need to watch out for. Discussing security assessments with Windows and Linux people generally ends with agreeable and disagreeable dialogs respectively when talking with contractors and vendors.
Doing Network Activity Analysis
- Threat > malicious traffic – Actually know what the traffic is
- Traffic > policy compliance – don’t assume that the tools keep you safe
Applications
- Big security assumptions. Not internally secured apps. Too much reliance on firewalls. CSRF, XSS and DNS Rebinding work w/o firewalls stopping them.
- Browsers need to be in scope
What is up with security guys trying to scare people with social engineering? Michael says why bother doing social engineering if you don’t have a security training and awareness program. He guarantees you will fail. Spend the money elsewhere.
The Gap Analysis of physical security includes video and lighting. The operations team will probably hate you for it though. Getting into “their” area… Be careful when testing physical security (guards, cameras, fences) w/o involving physical ops team.
Reviews and interviews need to happen with developers, architecture team, security coverage, and compliance. At the end of an assessment, you need to do remediation, transfer knowledge with with workshops, presentations, documentation, and scheduling a verification testing to make sure it is fixed. While it makes more money to do point in time evaluation without follow-up (because you can do the same review next year and say, “yep, its still broken and you didn’t fix it) it is better to get your customers actually secure and verify that they take the next steps.
Actual Security versus Compliance Security.
DNSSEC: What you don’t know will hurt you by Dean Bushmiller
This talk was very interesting to me because of my interest with DNS and DNS Rebinding. Dean passed out notes on this, so my notes are a little light, however I will see if I can post his slides here. But here are my notes for further research.
Read the following RFCs: DNS 1034, 1035 and DNSSEC 4033, 4034, 4035.
One of the big takeaways is that DNSSEC is meant to solve the integrity issues with DNS and does not solve confidentiality at all. It just verifies integrity.
All top-level domains are signed now, so when reading DNSSEC material online, ignore the island talk. A good site to check out is root-DNSSEC.org.
DNSSEC works by implementing PKI. One of the problems that people will face is key expiration. Screw that up and your site will be unavailable. Default is 30-day expiration period.
DNSSEC has a nonexistent domain protection. Subdomains are chained together in a circular logic and there is no way for a bad guy to add in a subdomain in the middle. This dumps all subdomains… All of them. All domains are enumerated and could make it easier for a malicious user to look at all your subdomains. They can already do this now, but this should prevent injection of bad subdomains into your domain.
An Introduction to Real Pen Testing: What you don’t learn at DefCon by Chip Meadows
What is a Penetration Test?
- Authorized test of the target (web app, network, system)
- Testing is the attempt to exploit vulnerabilities
- Not a scan, but a test
- Scanners like Saint and Nessus are part of a test but they are not the test, they are just a scan
Why Pen Test?
- Gain a knowledge of the true security posture of the first
- Satisfy regulatory requirements
- Compare past and present
PCI is not the silver bullet. Doesn’t really keep us secure.
Chip had a lot of other points that mimicked Michael Farnum’s earlier talk and they have been redacted from here, but he did mention the following tools and link that are also great for security guys to check out.
Testing Tools
- fling -ag ip add > Feed into scanner
- Hydra
- Msswlbruteforcer
- ikescan
- nikto
- burpsuite
- dir buster
- metasploit
- firewalk
- burp suite
http://vulnerabilityassessment.co.uk/Penetration%20Test.html
Wrap up
The talk that I was most interested in was the DNSSEC talk, but the most useful talks for most people are the security assessments and pen testing talks. I have been thinking about writing a talk on Agile Security and about how to integrate security with Agile development methods. Look for that in the near future.
One other note, I am testing my new setup made just for conferences. Well, I can use it for other things too, but I always worry about ‘open’ networks at hotels especially at security conferences. What I have done is setup dd-wrt on my home router with OpenVPN running on it as well. From my laptop (Mac Pro) I run Tunnelblick and get a VPN connection back home. This is cool because if someone is watching the traffic they will just see an encrypted stream from my laptop. That way, I don’t have to worry about whether or not they have WPA or just a plain open connection. All my traffic is encrypted at that point. OpenVPN was a little difficult to get setup and I found a lot of conflicting documentation, let me know and maybe I can piece together some instructions for the blog.
the agile admin 