Augusto Paes de Barros blog on many things cybersecurity.
A lot of noise out there about "Oddjob", a new malware that exploits the open session of the victim in online banking websites:
http://www.net-security.org/malware_news.php?id=1636
http://www.theregister.co.uk/2011/02/22/oddjob_banking_trojan/
Interesting, despite the fact that it's SOOOO 2005, 2007... :-)
5 Addictions of Information Security Professionals
Like most other disciplines, information security has its share of practices that are performed out of habit and might be detrimental to the organization. Here are a few such “addictions” that I have come to witness into world of information security:
- Long security policies: Process and detail-oriented individuals that we are, we cannot help but create wordy documents that might satisfy some auditors, but are too long to be read by others. Keep security policies and procedures short.
- Strict security mandates: Security documentation often codifies the desirable state of the security program without accounting for practical limitations of the business and humans who there. The policies are often unrealistic or overly-strict, making it impractical for people to follow them. Make security documents realistic.
- Information security gadgets: Since infosec professionals often have engineering or technical backgrounds, we love technology. As the result, we are easily excited to hear about new security gizmos that promise to take care of a security issue du jour. We forget that people and process are other critical elements of a security program. Exercise restraint when deploying new security tools.
- Best practices: We love making references to “best practices” without considering the extent to which they are applicable to the occasion or have been shown to actually reduce risk. Along these lines, we attempt to implement high-level frameworks such as ISO 27001/27002 without customizing them for the situation. Be judicious when picking which security controls you adapt.
- Prevention of security incidents: We often think in terms of preventing security incidents, setting ourselves up for failure. A more practical approach might be to focus on making it more costly to bypass your defenses and investing effort into breach detection and incident response. Reexamine the success factors of your security program.
For more thoughts along these lines, take a look at my earlier posts:
What a great post from Lenny Zeltser. I rarely see people mentioning the stuff he points out in "Strict security mandates" and "Best practices"; In my opinion they are among the biggest issues in security groups Today. Both can be seen as the "by the book security syndrome" that affects a lot of security managers.
Earlier Today I was thinking about how to provide guidance on information security decision making to new managers on the field. I realized that this is not the only area of information security that we don't have enough guidance available for new security managers. There's almost no content on security team organization, security operations, human resources (apart from the old discussions around certifications and "hiring hackers"), relationship with other groups within the organization and the development of a security strategy.
I know there's a lot of books, courses and other resources related to what an organization should do about information about security. However, the guidance for the manager who will conduct that group, focusing on the "how" instead of "what", is just not there.
Now, imagine yourself as a brand new security manager, with the new mission to assemble a security team for a big company. You know everything about PCI, ISO2700x, Firewalls, IDSes, cryptography. But how should you start? How many people do you need? What roles will they have? Can you define a job description and describe the kind of professional you want in each of those roles? What about the relationship with the auditors? How should you conduct that? By the way, what will you do next?
Those are the answers that I feel are not easily available for those starting in these positions. It seems to be content good enough for a book. I wonder, is it writable? Or is it the kind of content that depends so much of the context that will be useless? If you are planning to become a security manager, or has just started in the position, do you think this kind of guidance would be valuable to you?
I hope to see some good content like that on RSA next week. If are attending and have an opinion about this, please drop me a line, we can talk about it there.
In “Close Look at a Flu Outbreak Upends Some Common Wisdom,” Nicholas Bakalar writes:
If you or your child came down with influenza during the H1N1, or swine flu, outbreak in 2009, it may not have happened the way you thought it did.
A new study of a 2009 epidemic at a school in Pennsylvania has found that children most likely did not catch it by sitting near an infected classmate, and that adults who got sick were probably not infected by their own children.
Closing the school after the epidemic was under way did little to slow the rate of transmission, the study found, and the most common way the disease spread was a through child’s network of friends.
The work he discusses is “Role of social networks in shaping disease transmission during a community outbreak of 2009
H1N1 pandemic influenza” by Simon Cauchemeza, Achuyt Bhattaraib, Tiffany L. Marchbanksc, Ryan P. Faganb, Stephen Ostroffc, Neil M. Fergusona, David Swerdlowb, and the Pennsylvania H1N1 working group.The first thing that comes to mind is that closing schools is a best practice. It’s something that makes so much sense that it’s hard to argue against, even if it does no good. The next thing is look at what happens when they have data available to them. They can study their prescriptions and test to see if they did any good. But note how detailed the data is: social graphs, seating charts. This isn’t something we would obviously get from more detailed breach notices. It’s going to require in-depth investigations, and investigators who talk about their methods. VERIS is a step in this direction, and I’m looking forward to seeing critiques or even competitors that can help us move forward and learn.
But the data we have is the data we have, and while we work to get more, there’s a good deal that we can probably learn from what’s out there. We just have to be willing to ask if our practices really work.
He is right pointing that study has far more data than what we usually have available in security today. Unfortunately, if we proceed with the comparison, we will see that information about service providers (hosting, cloud, vulnerability management), development shops, supporting platforms and products and even training investments would be necessary in order to allow us to get conclusions such as those from the Flu study. I'm not saying that it's impossible or worthless, but we would need far more information sharing in order to achieve that level.
A friend ang colleague who is also a security guru and much better qualified than me and who admits that he is not a huge fan of enterprise architecture frameworks doesn’t think that “enterprise
architecture” is on a completely solid footing; he points out that it’s a major business for Gartner, following their takeover of Meta Group.He asks “Anton, you’re a systems engineer and hence familiar with large-scale modelling and design: what’s your take on the widespread use of ‘architecture’? Is it over-egging the pudding?”
Probably.
Its certainly is a heavily abused term. One that has been hijacked by marketing and owes more to articles in glossy magazines than engineering substance.One thing we are all aware of is that IT as a whole is subject to CHANGE. In fact Change Management is a very necessary skill in all aspects of the profession even if the practitioners do not admit to it.
Disciplines like ITIL bring change management to the forefront, and even in InfoSec we are well aware that unauthorized or unmanaged change can be precipitous.
The point here is that most of what engineers get taught about architecture is. on the one hand, about change in that they are building something new, but they don’t seem to be be taught to
“build-for-change”, that is changes to come. In fact it seems bl00dy difficult to get engineers to build for maintenance and repair. Its taken heavy financial incentive to get engineers to design for easy of assembly on some - not all - production lines. And that may conflict with ease of maintenance!Sidebar: All those Salvation Army Special PCs I’ve worked on, for
myself and as a social contribution, machines I’ve worked on for
clients, have stuck me as things that skin my knuckles when I try to
change hard drives, fuses or twist ribbon cables into a 21st century
artists rendering of a Gordian knot. Ease of maintenance they are not.I can understand how civil engineers or shipbuilders fail to consider ‘ease of change’; the effort to reposition a highway or a city because of a change in the requirement is high. However Jane Jacobs showed that city planners also don’t seem very inclined to learn form past mistakes and work to political rather than social agendas.
The Irony is that software and much of IT is in such heavy flux and so much of it is as amenable to change as silly-putty. Yet designers still have a mindset that is rooted in a more physical and more fixed world. Change, to many “software architects” means changing your button-bar or
your colour scheme. Big deal.Well OK, many are tied in by vendor ideas: can you change your mail user agent and still access your mail repository? Notionally I can because I keep all my mail on an IMAP server, but in reality the vendor-specific configuration means that if I changed between Thunderbird, KMail, Gmail,
Outlook, Pegasus, Elm, Balsa, Eudora or Evolution then I would have the better part of a day wasted in setting up all my accounts and the rebuilding of the local indexes. Not quite “vendor lock-in” but a high enough threshold to make change a chore.Now lets take a look at something else.
The Open Group Architecture Framework (TOGAF) is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture.
There’s a lot of material at
http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html
That TOC has a nice diagram showing “change management” last of all and not discussing it, and not addressing “designing for change”.But to address the question my colleague raised I focused on this:
http://www.opengroup.org/architecture/togaf8-doc/arch/chap30.html
“IT Architecture” and “IT Architect” are widely used but poorly defined
terms in the IT industry today. They are used to denote a variety of
practices and skills applied in a wide variety of IT domains. There is a
need for better classification to enable more implicit understanding of
what type of architect/architecture is being described.This lack of uniformity leads to difficulties for organizations seeking
to recruit or assign/promote staff to fill positions in the architecture
field. Because of the different usages of terms, there is often
misunderstanding and miscommunication between those seeking to recruit
for, and those seeking to fill, the various roles of the architect.I can’t agree more!
In fact this is an excellent page. But as I said to begin with, the conceptual model omits the fundamental assumption that is implicit in IT, that of change.
And Information Security is even more so!
