Bad guys are using Twitter to click on links that lead to malware. I've seen it. You've seen it. We both have almost fell for it. Simple advice... don't click on things from strangers, don't click on things from anyone for that matter. I wish I could make a bumper sticker like "Say No to Links" and have kids join a club called S.A.R.C. (Students Against Reckless Clicking).
So in summary, if you you don't know the person don't click the link on their Twitter feed or Twitter mention. If you do know the person, then reply, "What is this?" I've done it. About 75% of the time I either get no reply or they tell me they didn't send it and they probably got hacked. I'll see you all at the next S.A.R.C. meeting, there will be chips and dip.
Security Consulting Perspectives
I have worked as an Information Systems Security Engineer for ten years, please check back frequently as I share my thoughts and experiences.
Monday, March 12, 2012
Monday, February 27, 2012
Tidal Wave of Security Knowledge
![]() |
Courtesy of http://randomwikipedia.blogspot.com/ |
Here's a bit of advice I'm taking for myself. Learn policy first. Procedure and technology changes constantly. Policy is a slow moving target; a lame duck if you will. Some of the first things I'm targeting for reading is policy handbooks and security management practices. Then I figure I'll learn the technology tools once I've understood the meaning of the policies and its intent. I can't convince my group to do anything unless I can appear confident enough to understand policy.
On my wish list for reading are the DIACAP Handbook, the ISO 27000 series, and NIST Pubs. I've got an assortment of text books that should keep me very busy for the next year. I'll share any particularly driving excerpts I find here.
Wednesday, February 15, 2012
Who are you?
The following blog post inspired by this article:
And this clip from Anger Management, "Dave, who are you?":
IT Security Systems are designed to irritate you with just one question, "Who are you?" That's one of the biggest questions we want to know, "are you who you say you are?" And I got to tell you, after 10 years in the biz, you build up a complete distrust for everyone, and I mean everyone around you so you better be able to prove you are who you say you are. Somehow, we have to build an infallible way to customize the Identity proofing experience so it's customized to just you. The problem is, you are changing all the time, year to year, day to day, even second to second. The other problem is, you make it real easy for me to pretend I'm you. The real problem to that is, people and IT systems can be fooled real easy.
Now that we've identified the problem what are some of our methods? Usernames and passwords, hardware tokens, PINs, biometrics.... all of which are susceptible to theft, forgery, brute force attack, etc. "So tell us something we don't know Kamran!" I'm working on it... as you should be too.
Thursday, February 09, 2012
Back in full force
It's time to get back into blogging it's time for us a community (i.e. Business, Technology, Information Assurance) to share our experiences. You subscribe to my blog I'll follow your tweets/blogs whatever. I'll be posting soon.
Thursday, August 04, 2011
Stay alert on 3389
Internet Storm Center is seeing unusual peaks on Port 3389 which is used for Microsoft remote desktop connections. If you see any bizarre activity in your logs be a pal and report it. It will help the community prepare for what's ahead.
Wednesday, April 20, 2011
Reliance on tools versus knowledge
You can be dangerous with a hammer or a screwdriver if you don't know what you are doing. The analogy holds somewhat true when talking about security tools. No, you will not poke your eye out with an Intrusion Detection System but you sure could open yourself to a mess of problems if you do not know how to configure an IDS or any security device correctly. One of the biggest dangers we Network Engineers face is a strong reliance on the tools we are provide without a lot of knowledge on how to properly implement them.
Here's an example, a client-based firewall installed on a desktop computer is enabled at the default setting and left alone. Now some of the newer firewalls do have dummy rules in place for basic functions allowed (i.e. web surfing, email, etc.). But suddenly the user can't get to the network share folder or print to a networked printer. The desktop is also open to quite a few unnecessary ports and protocols (e.g. the computer will never be used as a web server but its setup to operate that way). Our user than promptly disables the firewall so he can continue working. The security tool in question was not implemented properly.
Here's the good news, we security consultants are trained to use these tools properly. Just remember we don't build around a solution, we build around a problem and then come up with approaches based on best security practices. A firewall, IDS, or authentication mechanism will only get you so far. Let's all strive to better security practitioners and use the knowledge given to us to get the job done.
Here's an example, a client-based firewall installed on a desktop computer is enabled at the default setting and left alone. Now some of the newer firewalls do have dummy rules in place for basic functions allowed (i.e. web surfing, email, etc.). But suddenly the user can't get to the network share folder or print to a networked printer. The desktop is also open to quite a few unnecessary ports and protocols (e.g. the computer will never be used as a web server but its setup to operate that way). Our user than promptly disables the firewall so he can continue working. The security tool in question was not implemented properly.
Here's the good news, we security consultants are trained to use these tools properly. Just remember we don't build around a solution, we build around a problem and then come up with approaches based on best security practices. A firewall, IDS, or authentication mechanism will only get you so far. Let's all strive to better security practitioners and use the knowledge given to us to get the job done.
Friday, April 08, 2011
How to Sell Security
A bold statement: How to Sell Security. But it is what we have to accomplish in order for those we support to buy-in to security practices. This could apply to any type of consulting practice but for us it is crucial. As security practitioners, we are in the know of why Information Assurance is so important to a business or information technology infrastructure. It is up to us to convince leadership and staff that this is important stuff, that it matters.
I was talking to a former customer, and a friend of mine, this morning. I asked him how things were going after sharing some of my own challenges at work. He told me that the biggest pain in the neck they were having was support calls they have to take. Their manager had recently come down on them for not getting system builds done on time. The reason for the lag was the engineers were instructed to take some of the support calls coming in, but due to setbacks and staffing shortages, the engineers are taking all of the calls coming in. The first thought in my mind was C I A. Confidentiality, Integrity, Availability, the three principles of security. The service of building new systems to support the infrastructure was unavailable to the consumer, therefore a risk was identified to the program. I relayed to my friend that I believed there day would go by much easier if they hired interns (which in his sector are easily attainable) to man the phones during business hours. I went further by advising him to put together a tech support handbook with easy, simple troubleshooting techniques to hand over to the interns. The interns should then in turn start recording the calls in the form of tickets. It could be a Excel spreadsheet or Remedy ticketing system, that doesn't matter. This would serve two functions:
I was talking to a former customer, and a friend of mine, this morning. I asked him how things were going after sharing some of my own challenges at work. He told me that the biggest pain in the neck they were having was support calls they have to take. Their manager had recently come down on them for not getting system builds done on time. The reason for the lag was the engineers were instructed to take some of the support calls coming in, but due to setbacks and staffing shortages, the engineers are taking all of the calls coming in. The first thought in my mind was C I A. Confidentiality, Integrity, Availability, the three principles of security. The service of building new systems to support the infrastructure was unavailable to the consumer, therefore a risk was identified to the program. I relayed to my friend that I believed there day would go by much easier if they hired interns (which in his sector are easily attainable) to man the phones during business hours. I went further by advising him to put together a tech support handbook with easy, simple troubleshooting techniques to hand over to the interns. The interns should then in turn start recording the calls in the form of tickets. It could be a Excel spreadsheet or Remedy ticketing system, that doesn't matter. This would serve two functions:
- The tickets could be used as metrics to identify whether certain kinds of problems were becoming more prevalent and to assign engineering time to resolve the issue permanently. This would also track overall effectiveness of the help desk support system in place to identify if more staffing is required.
- Open tickets; presumably calls that the intern could not fix themselves on the phone should be handled by the engineers. This way, instead of 15 minute interval interruptions in the day turn out to be maybe twice a day handling the most challenging cases the consumers are having.
And as simple as that, I sold an engineer on security. I sold him on a mechanism to improve availability and close a vulnerability whereas production was being halted due to trouble support calls.
I asked the engineer questions to figure out what his real needs are. I introduced a new idea and put it in terms of his business area. I made sure I applied (at least in my head) basic security practices such as assessing and identify risk, weighing mitigation techniques, and finally providing a solution that was effective but cheap to implement.
Remember that anything can be applied to Security, it's not all just firewalls and hackers. Security is an essential need in life in whatever we do, we need security. When you have identified a problem and want to convince someone, remember your training, and use what you have learned as Yoda has once said. I wish you luck and let me know if you have any interesting stories to share how you sold security.
Subscribe to:
Posts (Atom)