(ISC)2 Blog

What will be the next generation of security tools?

I was reading a interesting discussion on Linked-In days ago about security technologies tendencies and I became happy to read about some very interesting solutions/technologies that I never heard about it and some others I'm more familiar but with a new approach.

I will spend some time in the near future to study more some of them and blog the results here but my objective now is to promote a health discussion.

On the opinion of the ISC2 folks, what will be the next generation of security solutions? And by "next generation" I mean a technology that will evolve or be invented.

My opinion to start it:

- Application White-list;
- More sophisticated financial/regulatory fraud detection tools;
- Data Encryption 

Happy 2010 for all

Ethics (Kabay)

Fairly standard articles and slide decks on ethics.

Shariah and Cybercrime

From the International Journal of Cyber Criminology, "Shariah Law and Cyber-Sectarian Conflict: How can Islamic Criminal Law respond to cyber crime?"  This paper looks at the concepts in Islamic Shariah law that relate to specifically computer or information system related crimes.  The paper is possibly not a complete examination, but is not hopeful as regards the ability to criminalize cybercrime.  Also available as PDF.

Resilience - the missing link?

While reading IT Grundschutz, the German information security baseline standards, and in particular the BSI standard 100-4 on Business Continuity Management, I've been thinking about a curious gap that I believe has opened up between the fields of information security and business continuity. 

The way I think of it, 'resilience' (and related concepts such as 'over engineering', redundancy, automated failover and so forth) is very definitely an integral and essential part of 'business continuity' (in other words, keeping vital business operations running as near normally as possible, despite whatever threats and vulnerabilities might materialize).  Keeping unauthorized users out of the applications, systems and networks, preventing data and systems corruption (including that deliberately introduced by corrupt fraudsters, as well as incompetent or indolent users, designers, administrators, developers and managers), avoiding unplanned and unwelcome changes, avoiding/neutralizing malware and maintaining adequate IT performance and capacity are, for me, all important business process resilience controls, and are therefore all valid aspects of 'business continuity'. 

Avoiding or at least reducing the extent/impact of incidents, crises and disasters has got to be better than recovering from them, surely?

However, most 'business continuity' standards are purely concerned with 'Assume a disaster has happened: we need to prepare ourselves to cope with what happens next'.  They talk about timely resumption and recovery, all post-event of course, while most information security standards major on maintaining confidentiality, with a few token nods towards data, network, application or sysem integrity but very little in the way of process or personal integrity and even less about availability, other than referring to 'business continuity' (often meaning IT Disaster Recovery in fact) as if that settles the matter.

Most organizations I've worked with seem to separate information security from business continuity management, in the same way that most separate physical from information security, and have other stovepipes for fraud, risk management and compliance. 

So what on Earth happened to resilience?  Where did it go?  Have you seen it, hiding in a corner somewhere?  While I totally support the need for contingency planning to prepare the organization to cope more effectively with disasters that result from the failure of preventive controls, I strongly suspect that many organizations would be better off diverting some of their not inconsiderable business continuity budgets towards resilience and prevention, or at the very least creating a more coherent strategy linking information security with business continuity through their common interest in resilience.

I'd be especially interested to hear from anyone who is familiar with standards, guidelines etc. that cover resilience (as outlined above) in some detail, whether they claim to cover information security, business continuity or something else entirely.  Go on, give us a clue about where to find the missing field.

... 97, 98, 99, 100, coming, ready or not!

Kind regards,
Gary Hinson
ISO27001security.com
NoticeBored.com

PS  A well-written piece on Investing in software resiliency by Dr. C. Warren Axelrod, U.S. Cyber Consequences Unit, lays out several aspects of resilience, including a number of availability threats, software development process issues and of course a range of IT resilience controls such as fault tolerance and failure recovery, system fail-over and recovery and restoration.  Even cloud computing merits a mention.  However, once again, business continuity and the wider aspects of identifying and maintaining critical business functions are largely implied. 

US DoD SDLC

The US Defense Dept has a system for everything, and most are fairly structured.  Their Integrated Defense Acquisition, Technology and Logistics Life Cycle Management System Chart is no exception.  However, if you pay attention, it does provide a detailed structure and process for secure development.  (Warning: their cert is self signed, and your browser may object.)

You can also get the chart PDF from https://acc.dau.mil/IFC/pdfs/Front_Ver_534_June_15_2009_34x22.pdf

Android Insecurity

Late last year, a nefarious banking app was discovered on the Android phone marketplace.  This, I'm afraid, is just the beginning.

Doing some Android phone development recently, I have gotten some hands-on experience with how an application is deployed to the Android Marketplace.  One big difference between the Google and Apple mobile software stores is that Apple vets and approves each app before it is made available for public download.  With Android, anyone who pays the $25 registration can upload an application to the marketplace.

To upload an application, it first must be signed with your own digital signature.  This signature need not be certified--you can create one yourself and it is just as valid as one issued by Verisign.  Signing your application is the only security requirement that must be met before uploading to the marketplace.  The information your submit to create your Android developer account is also not reviewed or verified. 

If your application is free, then anyone with a compatible Android phone can begin downloading and using it.  If the application needs to connect to the internet, then during the installation the user is notified "This application has access to the following:  Network communication, full Internet access," to which the user clicks OK to proceed with the install.

There are no alerts about the digital signature coming from untrusted or unknown source.  All applications are implicitly trusted.  My Android phone has 800 Mhz processor with 256MB RAM, a worth addition to any botnet. 

The current protections for mobile applications remind me of web sites in the mid to late 90s when e-commerce was just starting to get off the ground and viruses and botnets weren't daily news (and desktop PCs didn't have the same power that we now carry in our pocket.)  People just trusted anything they clicked, and bad guys realized this and quickly developed ways to exploit this blind trust.  Now that cyber crime has become much more savvy and organized, they working feverishly to exploit this new mobile vector. 

I know mobile apps still have that wow factor, but we have to learn from the past and treat all Internet enabled devices as attractive targets for attack today.  These mobile OSes need to have the same protections we apply to desktop PCs.  We should not continue blindly assuming that the focus of attack is the desktop PC and not mobile devices, even though they all have similar hardware specs and are connected to the same Internet.  Otherwise, this is security by obscurity, which does little else but to give us a false sense of security.

Lack of Communication

  Credit Card Brands Lack of Communication

As most of you in the world of PCI already know MasterCard once again threw another grenade this past week with several PCI enforcement rule changes, this article is not about those changes (see MasterCards 2 Step) for that discussion. I want to discuss the card brands communication/dissemination of PCI rule changes, or lack thereof! I know this is an area we are all in agreement.For example when any of the card brands do make rule changes in how they enforce PCI, they do not seem to have a defined process on how they disseminate it, just throw it up on some small corner of our website and everyone will figure it out approach. I only found out about it the day it came out on MasterCard’s PCI merchant web page only because I have many news alerts (Google, ect.) and monitoring applications that watch for these things.

Prior to bringing this significant change to my upper management, I wanted to get as much clarification on the changes and how they affected my organization as possible. Of course when contacting my acquiring bank they had no idea about the change, let alone an interpretation of it. And of course having discussion with colleagues in my field, they were in some cases as much in the card as I was, this is of course with the exception of one (you know who you are).

After getting some clarification from one of closest professional friends “the PCI Guru“ I decided to take this information to my director, after speaking to some of the changes I was asked to provide supporting links and/ or official documentation that could support all of my statements. And other than MasterCard’s website (with the horrible layout and merchant table) the only other reference that I could show was a another blog.

My director found it odd this information was not on the PCI-SSC website, our acquiring banks PCI portal (which I think just redirects to the PCI-SSC site) or any other official website at all. And that MasterCard’s website went into little detail about the changes.

This takes me into my main discussion of why in 2009 5-6 years after PCI was born, can’t the card brands have some sort of formal defined process to manage the dissemination of PCI enforcement rule changes. I understand they all act independently (particularly now with MC co-driving the PCI bus now with VISA) and that’s cool, but how hard is it to create one.

Case in point to my knowledge the card brands when making an enforcement rule change have never given a warning ahead of time, or explained the changes in great detail, many times leaving  unanswered questions that the QSA’s, banks and PCI compliance officers have to figure out as the months go by.

I would like to see some agree upon (heck they could do this independently, just do it) process on how these enforcement rule changes are communicated. For example I think that both acquiring banks and the QSA firms should be made aware of these changes first and non-publicly and in the case of the banks by direct channels.

After a 30-60 day period where both the banks and the QSA’s obtain a clear an accurate understating of these changes, through both dialogue and supporting documentation from the card brands, then the merchants and service providers should be notified directly by their acquiring banks. In my opinion that is the information communication flow I would like to see and think would serve us all best.

With regards to posting of this information once it is public; first I would like to see all the credit card brands build well defined PCI portals on each of the websites that contain their own specific supporting documentation on their rules with regards to PCI enforcement. Second and I would like to see the card brands work with the PCI-SSC website and have links on the PCI-SSC website that would point to the card brands individual web portals (come on how hard is it to keep a link up to date!

Hopefully one day I will click my heals and PCI RSS feeds will suddenly appear on the card brands websites . . . . . . ok it didn’t work!).

70 Years after Bletchley Park, People are Still the Key

Like many fields, the global recession has taken a toll on the information security profession. As I reflect on the challenges many of our members are facing, the contributions of those working at Bletchley Park decades ago puts the events of the last year into perspective and is a good reminder that even in the darkest times, people are at the root of effective security.

In an article recently written by former (ISC)² Board of Directors and European Advisory Board member Dr. Peter Berlich, CISSP-ISSMP, CISA, CISM, we're reminded of the vital impact the people working at this historic site had on the outcome of World War II. Today, it is in very urgent need of structural repair, without which the site and many of its historic buildings and artifacts could be lost. 

But Bletchley Park is more than a building. It's the people within its walls that saved lives. As many economies today still struggle to emerge from a devastating recession and information security teams are faced with a shortage of qualified people to fill the slots they've managed to hold onto, and management temptation and pressure to bypass security to make sales at any cost, it's critical to remember that technology alone can't protect precious data assets. 

Seventy years after Bletchley Park began its wartime function, people remain the most critical element to effective security.   

Lessons from counter-terrorism

While being firmly based in the world of physical security and anti-terrorism, Eagle Eyes, a US Air Force Office of Special Investigations program, has worthwhile lessons for us in information security. 

Through the Air Force program, civilians (as welll as military people, presumably) are encouraged to be alert towards, and report, suspicious activities such as:

• Surveillance -- someone recording or monitoring activities, including the use of cameras or binoculars.
• Elicitation -- anyone trying to gain information by mail, fax, telephone or in person about military operations or people.
• Tests of security -- attempts to measure reaction to security breaches or to penetrate physical security barriers or procedures.
• Acquiring supplies -- purchasing or stealing explosives, weapons, ammunition, uniforms, decals, flight manuals, passes or badges.
• Suspicious persons out of place -- people who don't seem to belong in the workplace, neighborhood or business establishment.
• Dry run -- putting people into position and moving them about without actually committing a terrorist act.
• Deploying assets -- people and supplies getting into position to commit the act.

There are direct analogies and in fact very similar threats in the civilian world from social engineers, hackers, industrial spies, unethical competitors, misguided contractors and disloyal employees.  Employees should equally be encouraged to notice and report suspicious activities such as:

• Surveillance -- someone snooping around the facilties, offices or IT systems, taking an unusual interest in CCTV cameras, alarms, access control systems, procedures for issuing staff passes or network IDs etc., and maybe photographing things.  This includes "lookouts".
• Elicitation -- anyone trying to gain information by email, fax, phone, letter or in person about commercial operations, people, facilities, IT systems and networks.  Anyone casually inquiring about sensitive projects, activities, facilities, systems or sites should immediately raise eyebrows at the very least.
• Tests of security -- people claiming they are 'just checking for vulnerabilities' or 'testing the security arrangements' should invariably be reported via the normal incident reporting process (generally, a quick call or email to the IT Help Desk or Security), even if they are legitimately employed to do this and present authentic credentials [employee awareness and incident responses are often part of such tests].  How often do we blithely ignore "IT people" or "maintenance engineers" fiddling around in the network cupboards or computer systems: they could easily be installing bugs, network sniffers or taps.
• Acquiring supplies -- copying or stealing employee credentials, staff passes, visitor IDs, passwords, user IDs, directories, site maps etc., and acquiring knowledge in other ways such as asking probing questions on the phone or on mailing lists, email, blogs, IM, Skype or whatever.
• Suspicious persons out of place -- people who don't seem to belong in the office/site, no matter what clothes they are wearing, toolboxes they are carrying, passes they present or whatever.  Report them anyway - better safe than sorry and - if your security function is truly switched on - you might even earn yourself a prize or commendation.  Again, this includes "lookouts".
• Dry run -- accessing facilities, networks, systems or whatever without apparently committing an attack as such.  The most effective types of social engineering and walk-in intrusions are over before anyone realises anything has happened.  Yes, they happen "in broad daylight".  Brazenly.  Even old-school bank robbers (who are renowned more for the size of their gonads than the size of their brains) case the joint first, and - again - post lookouts.  
• Deploying assets -- putting people (lookouts), malware, bugs, systems and/or miguided trust relationships into place as a prelude to a full-blown attack. A classic example would be unauthorized privileged accounts on a system, curious new rules appearing on a firewall, and new employees, contractors, consultants, advisors or auditors who seem just a bit too eager to find out all there is to know about security, sensitive projects, customer lists, secret recipes etc.

[According to an article about the Eagle Eyes program in FloridaToday, Bryan Gallagher, a special agent with the Air Force Office of Special Investigations, said Air Force personnel get annual training on terrorism awareness.  Oh oh, if "annual training" means what I think it does, the US Air Force has fallen into the same trap as far too many corporations who place their faith in "annual security awareness training" for their employees.  Come on guys, get with the program!  Security awareness deserves far more than the usual excruiciating once-a-year sheep-dip session.  Did you learn to drive with one driving lesson a year?  No!  You took a series of intense lessons over a period, and (hopefully) continue learning every time you drive anywhere.  Are information security or counterterrorism any less important than driving?]

Kind regards,
Gary Hinson
NoticeBored.com