Everyone who reads this post has probably heard of Dr. Randy Pausch's world famous "Last Lecture". Anyone who has not heard of it must stop reading now and go view it.
When the new came of Pausch's death on July 25, the editors of Communications of the ACM felt there could be no greater tribute than to share his own words[...]
What about advice for CS teachers and professors?
That it's time for us to start being more honest with ourselves about what our field is and how we should approach teaching it. Personally, I think that if we had named the field "Information Engineering" as opposed to "Computer Science", we would have had a better culture for the discipline. For example, CS departments are notorious for not instilling concepts like testing and validation the way many other engineering disciplines do.
Source: Wisdom from Randy Pausch, Leah Hoffmann. Communications of the ACM, September 2008, Vol. 51, No 9, p19. (full text pdf, account required)
What else is there to say?
As information security professionals, we are faced with this every day.
One might even leap to the conclusion that had the field been approached as a mature engineering discipline, there would be no need to have as many dedicated security professionals as we do now.
An article well worth reading.
Google released its own web browser, named Chrome, yesterday, and many blog posts have already been dedicated to it.
I agree with Martin McKeay's judgement: "So what?" The browser seems to have some interesting ideas, but it does not warrant switching over it. I'm not sure if Google is trying to make a serious attempt at getting into the desktop browser market, or if they want to use the product to push the envelope of technology by demonstrating that certain enhancements are possible in production-quality code.
The fact that Chrome installs (and runs) on Windows without administrator privileges
is interesting though. Another thing that we have to remember is that
Google will probably package it with their bundle. Basically, anyone
downloading Picasa or Google Earth will probably end up with a copy on
their system. Even if they never use that, it is yet another source of
potentially insecure code.
We'll see; I haven't seen anything that would prompt me to go in
and switch my default browser to Chrome. I'll use it to see if a page
renders properly when I'm testing something, but I also do that with
IE, FF, Konqueror, Opera, Safari, etc.
I'm not entirely sure that Google's strategy is for this. I agree
with the observation made in Martin's podcast: this will probably take
away from Firefox's market share much more than it will take away from
IE (if any effect can be seen at all)
Every now and then, I dabble in coding. Every time I develop software, I realize that writing code that does what it supposed to do is not all that hard. However, writing code that does exactly what it supposed to do, and only what it is supposed to do, is incredibly hard.
Automated application testing is a very valuable tool. Systematic and complete checking of all inputs and outputs is something that is incredibly tedious, labor intensive, and as a result, takes a lot of time and patience. That also makes it a very expensive process to do manually.
Good tools are available to test each input element and each output element of a web application, and their use should be far more wide-spread than it is now.
Web application security is about much more though; it involves session handling, authentication and authorization, access control, cookie theft, replay attacks, URL manipulation, intrusion detection (and prevention), etc., etc. Good people who understand these issues in-depth are rare and deserve all the credits that one may give them.
In addition to using automated tools to test the application, peer-review of code is a good thing and it may catch ugly solutions or design flaws. Using "eyes on lines" it becomes much easier to catch backdoors, or other code vulnerabilities that might not be obvious to find using automated tools.
All in all, we need to do much more quality control on code before it gets released. Automated testing tools must be run before code gets released and careful peer-review of code should be embedded in the full software development cycle.
The nice people over at SANS just put up my course details. Before registering, please contact me for a referral code, or send me an email at sans.mentor@leune.com.
I got a report today from an employee who had just gotten a call from someone claiming to be either working for Dell, or on behalf of Dell. The caller's story was that they were working for the Dell credit card payment office, and that they wanted to validate a certain purchase. If we would please provide them with some additional information of one of our students, Dell would be able to help this person with their purchase much better.
The employee did not provide the information, terminated the phone call, and reported it to me.
So far, so good!
However, as my discussion with the employee continued, it did not so much bother her that someone called her for that kind of information, but much more so that she could not validate that it was indeed someone calling on behalf of Dell.
However much I tried to explain that it does not matter if that person worked for Dell or not, because the issue that Dell might have with one of our students is an issue between that student and Dell; we are in no way part of that. Somehow, that message just did not sink in.
So, now I am left with a gnawing doubt; while no information was shared, the request was denied for the wrong reasons.
If a social engineer is able to convince someone that they are doing the right thing by disclosing information, success is practically guaranteed. After all, people WANT to do the right thing!
I guess it is time to kick up our internal training another notch: no matter what the reason is that someone calls, do NOT disclose ANY information, unless you are CERTAIN that you are:
1) trained to disclose that information
2) authorized to disclose that information
3) verifying who you are disclosing that information to
4) certain about what you are disclosing
5) documenting that you are disclosing it.
For most universities and colleges, today is the first day of the new academic year.
The joys of overfull parking lots, stuffed cafeterias around lunch time, and battling through waves and waves of students on your way to your next meeting is offset greatly by the presence of "learning".
It sounds a little romantic, and possibly even naive and/or imaginary, but working in higher education has always given me the feeling that being around so many people who are learning has something reinvigorating.
With the month of August coming to an end, schools, colleges and universities all over the country are starting up again. For IT departments in higher education, it means that the busiest part of the year is over. Because the effect of service degradation is the lowest, the summer break is the time where most large projects are undertaken. For many schools this means infrastructure upgrades, upgrading/restoring labs, getting new faculty equipment ready in time for the new school year, etc.
For us as information security professionals, the summer is a good time to review our IT policies, revise them where necessary and get them approved by management and rolled out to our constituencies.
This year, we put the emphasis on revising our acceptable use policy and developing a new policy which was designed to reduce the amount of rogue networking equipment connected to our network. These two policies will be the topic of another post.
Having developed new and existing policies during the summer, the beginning of the school year is a good time for a security awareness campaign. When students come back after the break, they are a prime target for a campaign that explains proper use of IT infrastructure, or more importantly, improper use.
In our case, we are kicking off with a five-week poster campaign. Each week, we'll be putting up different posters covering different themes. This year's themes are:
- Protect your data: make backups often and keep them safe
- Sharing copyrighted files is usually illegal, and your are not anonymous
- Don't become a victim of phishing. Think before sharing personal information via mail, email, telephone, the web or phone. Always verify who you are sharing it with
- Before you click, ask yourself: is it safe? Be ware of unexpected email attachments and unknown websites
- You count on your password to keep your data and identity safe. Return the favor- Don't share your password with anyone
The posters have all been designed in-house, and they look awesome.
Since our primary audience consists predominantly of freshmen, it is near impossible to get a good baseline in place. As such, we'll have to measure the success of the campaign by comparing the number of incidents per constituent compared to last year. Hopefully it will be lower.
Having said that, we'll have to compensate (somehow ) for the fact that by increasing security awareness, the amount of incidents that is actually reported usually goes up too.
After these five weeks, we'll be in the first week of October, which is security awareness month. Throughout October, we will provide education and training in the form of targeted workshops and seminars for students and employees.
Hopefully this will put us in a position where the people who are using IT resources to handle sensitive information are aware of the fact that they are doing so, and behave accordingly.
Episode 1
Episode 2
Episode 3
Episode 4
Episode 5
Episode 6
Episode 7
Episode 8
SANS courses have a reputation as being the best technical vendor-neutral security training available at the moment. I am pleased to announce that I have recently joined the SANS Mentor program, and I am currently preparing to host a SEC 504 Hacker Techniques, Exploits & Incident Handling class. The class prepares the attendees for the GIAC certified incident handler (GCIH) certification.
We are currently looking at starting the class somewhere around Christmas. Mentor classes run for 10 consecutive weeks for two hours a week, usually in the early evening.
If you are interested in taking the class through the Mentor program, and if you are able (and willing) to travel to Long Island (NY) to take the class, please let me know.
Exact dates and times have not yet been determined, so I can work with you on that aspect. For now, we are looking at holding the classes in Garden City, or in Hauppage.
Defcon was awesome.
I got to meet a whole lot of people who I wanted to say hello to, a whole bunch of people who I had never heard of but enjoyed hanging out with, and I was unable to hook up with some persons who I had really wanted to see. Oh well, there is always next year!
I'm not going in much detail; if you were there you know what it was like and if you weren't, I don't think I would be able to convey the Con as a whole. This picture captures it fairly well though ;)
