<![CDATA[[SecurityRatty] tag: programmers]]> http://securityratty.com/tag/programmers Fri, 16 May 2008 07:05:09 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[SOA Security in Real Life]]> http://securityratty.com/article/444bcf73dc28e9ef7ab7d0cf7b145901 http://securityratty.com/article/444bcf73dc28e9ef7ab7d0cf7b145901 I started off my last article on SOA Security this way:


When I park my car in the garage, I lock it. Why? Well, although I would hate for someone to steal my snow shovel and hockey sticks, my car is much more valuable to me. Security is about managing risk, specifically protecting valuable assets like my car. I have a higher level of protection on my car than on my garage. In dollar terms, the contents of my garage are orders of magnitude less valuable than my car. I could spend a lot of money fortifying my garage, and that would add some security to my car while it is parked there, but it is not a cost-effective investment. First, my car is the asset of value, and second the garage - no matter how well protected it is - doesn't move. 

Car manufacturers know this, insurance companies know this, consumers know this. Even media publishers know, yet in the common enterprise, programmers and architects seem to roam in ignorance. Your average download of a Michael Bolton song carries a far higher level of security than valuable user data, like passwords, social security numbers, and credit card details. Why do we keep protecting critical data with point-to-point security solutions (like SSL) that protect the transmission channel, but leave the valuable assets being transported wide open everywhere else? This is a critical question that needs to be answered in order to successfully add an effective layer of security to an SOA.


Well guess what happened last weekend? I always do lock my car in the garage, but last week I came home with an armful of holiday cheer and forgot. I went out to the garage over the weekend and noticed that a local knucklehead who could see that the car was unlocked tried to jimmy the lock on my garage door, and busted off a piece of wood before giving up (probably when they saw the sign that said the garage was monitored).

The response of the police actually further supports my assertion that security is about assets not threats. I called the police and said someone tried to jimmy my garage door. They said its a holiday weekend, call back on Monday and get a case number. This disturbed me not at all. All they are going to do is record a threat (or security event) metric anyway.

Now in a hypothetical scenario if my car was compromised it would have been a completely different response from both me and the police; why is it different urgency? Not because of the threat and intent which  were similar in both scenarios, but its the fact that the asset was put into motion that's what makes it important.

For infosec what do we learn? Infosec is spending waaayyyy too much time and money protecting garages and not enough protecting assets.
]]> Sun, 30 Nov 2008 14:29:17 +0000 soa soa security security car manufacturers garage security event garage door car point-to-point security solutions SOA Security in Real Life <![CDATA[Will Code Malware for Financial Incentives]]> http://securityratty.com/article/30eebfa1383ce3a671879e2f1f0af37d http://securityratty.com/article/30eebfa1383ce3a671879e2f1f0af37d
A couple of hundred dollars can indeed get you state of the art undetectable piece of malware with post-purchase service in the form of automatic lower detection rate for sure, but what happens when the vendors of such releases start vertically integrating just like everyone else, and start offering OS-independent spamming, flooding, modifications and tweaking of popular crimeware kits in the very same fashion? The quality assurance process gets centralized into the hands of experienced programmers that have been developing cybercrime facilitating tools for years.

It's interesting to monitor the pricing schemes that they implement. For instance, the modularity of a particular malware, that is the additional functions that a buyer may want or not want, increase or decrease the price respectively. Others, tend to leave the price open topic by only mentioning the starting price for their services and they increasing it again in open topic fashion.

Let's take look at some recently advertised (translated) "malware coding for hire" propositions, highlighting some of the latest developments in their pricing strategies :

Proposition 1 :
"Programs and scripts under the following categories are accepted :
grabbers; spamming tools for forums, spamming tools for social networking sites, modifications of admin panels for (popular crimeware kits), phishing pages

Platform: software running on MAC OS to Windows
Multitasking: have the capacity to work on multiple projects
Speed and responsibility: at the highest level
Pre-payment for new customers: 50% of the whole price, 30% pre-pay of the whole price for repreated customers
Support: Paid
Rates: starting from 100 euros

If, after speaking ultimate price, you decide to add to your order something else - the price change. Prepare the job immediately, which will understand what to do and how much it will cost you, if you have any suggestions for a price, then lays them immediately and not after the work is completed. If you order something that requires parsing your logs, and their continued use, you agree to provide "a significant portion of the logs, so that after putting the project did not raise misunderstandings due to the fact that some logs are no longer "fresh", because of their "uniqueness". In this case, for the finalization of the project will be charged an additional fee."

This is an example of an "open topic pricing scheme" with the vendor offering the possibility to code the malware or the tool for any price above 100 euro based on what he perceives as features included within worth the price.

Proposition 2:
"Starting price for my malware is 250 EUR. Additional modules like P2P features, source code for a particular module go for an additional 50 EUR. If you're paying in another currency the price is 200 GBP or 395 dollars. I sell only ten copies of the builder so hurry up. The trading process is simple - a password protected file with the malware is sent to you so you can see the files inside. You then sent the money and I mail you back the password. If you don't like this way you lose. 

I can also offer you another deal, I will share the complete source code in exchange to access to a botnet with at least 4000 infected hosts because I don't have time to play around with me bot right now.

This proposition is particularly interesting because the seller is introducing basic understanding of exchange rates, but most of all because he's in fact offering a direct bargain in the form of access to a botnet in exchange for a complete source code of his malware bot. Both propositions are also great examples that vendors engage by keeping their current and potential customers up-to-date with TODO lists of features to come next to the usual CHANGELOGS, and, of course,  establish trust by allowing potential customers to take a peek at the source code of the malware they're about to purchase.

Related posts:
Coding Spyware and Malware for Hire
The Underground Economy's Supply of Goods and Services
The Dynamics of the Malware Industry - Proprietary Malware Tools
Using Market Forces to Disrupt Botnets
Multiple Firewalls Bypassing Verification on Demand
Managed Spamming Appliances - The Future of Spam
Localizing Cybercrime - Cultural Diversity on Demand
E-crime and Socioeconomic Factors
Russia's FSB vs Cybercrime
Malware as a Web Service
Localizing Open Source Malware
Quality and Assurance in Malware Attacks
Benchmarking and Optimising Malware
]]> Tue, 18 Nov 2008 10:57:55 +0000 malware code source malware malware attacks malware bot proprietary malware tools source code complete source code tools Will Code Malware for Financial Incentives <![CDATA[Address Spoofing Flaw Allows Googles Chrome Websites Impersonation]]> http://securityratty.com/article/c707b16142517ab2932508386d37109e http://securityratty.com/article/c707b16142517ab2932508386d37109e Sun, 26 Oct 2008 19:04:47 +0000 googles chrome browser researcher liu die mountain view faulty code websites business bureau vulnerability research lab google Address Spoofing Flaw Allows Googles Chrome Websites Impersonation <![CDATA[A New Way to Back Up Digital Files on paper]]> http://securityratty.com/article/f29b43ae964909cbeacf815e65f8018e http://securityratty.com/article/f29b43ae964909cbeacf815e65f8018e This is pretty funny — a free open source application where you can backup your data by printing it, on paper, in a bar code format. A friend of mine says he tried it and that it even works –

PaperBack is a free application that allows you to back up your precious files on the ordinary paper in the form of the oversized bitmaps. If you have a good laser printer with the 600 dpi resolution, you can save up to 500,000 bytes of uncompressed data on the single A4/Letter sheet. Integrated packer allows for much better data density - up to 3,000,000+ (three megabytes) of C code per page.

You may ask - why? Why, for heaven’s sake, do I need to make paper backups, if there are so many alternative possibilities like CD-R’s, DVD±R’s, memory sticks, flash cards, hard disks, streamer tapes, ZIP drives, network storages, magnetooptical cartridges, and even 8-inch double-sided floppy disks formatted for DEC PDP-11? (I still have some). The answer is simple: you don’t. However, by looking on CD or magnetic tape, you are not able to tell whether your data is readable or not. You must insert your medium into the drive (if you have one!) and try to read it.

Paper is different. Do you remember the punched cards? EBCDIC and all this stuff. For years, cards were the main storage medium for the source code. I agree that 100K+ programs were… unhandly, but hey, only real programmers dared to write applications of this size. And used cards were good as notepads, too. Punched tapes were also common. And even the most weird codings, like CDC or EBCDIC, were readable by humans (I mean, by real programmers).

Read the whole thing here.

]]> Thu, 04 Sep 2008 04:28:19 +0000 paper code source code paper backups real programmers dared data data density real programmers flash cards A New Way to Back Up Digital Files on paper <![CDATA[A Blast From The Past: Linux-Kernel Archives 1998]]> http://securityratty.com/article/bf888f833de4fd52627ed84aef931357 http://securityratty.com/article/bf888f833de4fd52627ed84aef931357 Oddly enough, someone emailed me this quote, found an email signature documented in 1998, from the Linux-Kernel archives:

“Linux is a movement, a philosophy, where programmers and technical people take control of their own destiny.”  — Tim Bass

Ref:  Email signature, Re: Future of 2.0.36, G.W. Wettstein (greg@wind.enjellic.com), Sat, 24 Oct 1998 10:09:27 -0500

]]> Sun, 20 Jul 2008 01:00:51 +0000 linux-kernel archives linux email signature tim bass technical people philosophy oddly programmers future A Blast From The Past: Linux-Kernel Archives 1998 <![CDATA[Simple oversight at TNS Infratest exposes participant information]]> http://securityratty.com/article/ca9bbb88145ecdbedb20b4a7aa81936a http://securityratty.com/article/ca9bbb88145ecdbedb20b4a7aa81936a Security Breach

Date Reported:
7/4/08

Organization:
Taylor Nelson Sofres plc (TNS)

Contractor/Consultant/Branch:
TNS Infratest

Victims:
Survey participants

Number Affected:
41,000

Types of Data:
"Name and address, date of birth, email address and phone numbers", "Some of the data included monthly income, education, bank account information, health insurance data, and which credit cards are used"

Breach Description:
"The scientific journal of the Chaos Computer Club (CCC), Die Datenschleuder, reports that market research firm TNS Infratest/Emnid has lost 41,000 private data records of their survey participants."

Reference URL:
Chaos Computer Club e.V.
The Inquirer

Report Credit:
Chaos Computer Club e.V.

Response:
From the online sources cited above:

TOP MARKET RESEARCH firm TNS Infratest/Emnid has 'lost' 41,000 private data records of its survey participants, the Chaos Computer Club (CCC) has revealed in its official organ Die Datenschleuder.

As the magazine reports [1], it was possible for participants to read master data records and consumer profiles without bypassing even basic security measures.

Access to the comprehensive survey results could be gained by simply changing the customer ID number in the browser's address bar.
[Evan] This type of development mistake too common.  The vulnerability is very easy to find by good pen testers and the bad guys.  Actually, I am surprised that we don't hear about more of these types of breaches.

Besides name and address, the data records included date of birth, email address and phone number.

Many records also included very sensitive information: monthly income, education, bank account information, health insurance data, if and which credit cards are used, which electronic devices are used in the household, children's ages and yet more private data.
[Evan] Clearly this is some very sensitive information, all provided by people completing surveys.

"TNS Infratest made a beginner's mistake in their software development. This is unprofessional, grossly negligent and above all deeply worrying," commented CCC spokesman Dirk Engling regarding the incident.
[Evan] Mr. Engling is dead on.  I couldn't have said it better myself.

"As this information is very sensitive, where abuse such as identity theft or its use in connection with burglary cannot be excluded, THS Infratest needs to inform the victims immediately," he continued

This case continues a disastrous, never-ending series of information leaks of data held by public and private sector organisations.

The need for more strict control of sensitive data collections is evidenced by the recent snooping affairs by German Telecom as well as the data leaks from the "Meldeämtern" (registration of address offices).

It is obvious here that data security only plays a minor role in companies.
[Evan] Very sad, but very true.  Too many organizations still take the wrong view of information security as a "cost center" instead of a business driver.  Well designed and managed information security programs, the ones that are aligned with the business and not IT, can actually provide value to the business.

"Especially for companies surveying the most confidential data, the highest security standards have to apply," said Engling.

The press team of the Chaos Computer Club is available for questions at the following addresses:
  • presse@ccc.de (preferred)
  • 0700-CHAOSFON (0700 - 24267366)

Commentary:
TNS is a large company, a large company with resources to hire good management, programmers, and information security personnel.  What is the excuse for making such a significant, yet simple oversight?  There are a number of controls that could have reduced the risk of this occurring.

One a secondary note, but no less important in my opinion.  It seems that people (in general) provide too much information willingly, without understanding what the risks could be.  Personally, I rarely complete surveys that ask me for personally identifiable information (name, address, etc.).  I suggest that you give some serious thought to providing any of your personal information.  Ask yourself if you trust the organization collecting your information.  If so, question what your trust is based on.  Do NOT hesitate to ask questions and err on the side of caution.

Past Breaches:
Unknown


]]> Wed, 09 Jul 2008 19:37:10 +0000 information records master data records sensitive information sensitive information leaks personal information data bank account information Simple oversight at TNS Infratest exposes participant information <![CDATA[Mashup of the Titans]]> http://securityratty.com/article/6289294023616c0d4219941919c976a5 http://securityratty.com/article/6289294023616c0d4219941919c976a5 Information Security - an Oxymoron for the information age
“Always the beautiful answer who asks a more beautiful question.” e. e. cummings
...or why i am with Gelernter

This is a mashup of Saltzer & Schroeder's famous information security principles with David Gelernter's Manifesto.

The premise of this mashup is to examine the paper by Saltzer and Schroeder which was written in 1975 and serves as the basis for most information security programs against the Gelernter's manifesto as to where computing is actually going. Each of the eight principles in Saltzer and Schroeder's paper is listed in order, and followed by select excerpts of Gelernter's manifesto. This comparison is to examine theoretical information security principles vis a vis the actual utility of modern information systems. I will not make an attempt to reconcile theory and practice, but will point out where the two schools of thought agree. In fairness, Saltzer and Schroeder's paper was written 25 years before Gelernter's, however Saltzer and Schroeder's principles dominate the thinking about information security to this day and so its important to view them side by side with Gelernter's thinking on the direction of computing.

Saltzer and Schroeder:
"a) Economy of mechanism: Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths). As a result, techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential."

Gelernter:
"9. The computing future is based on "cyberbodies" — self-contained, neatly-ordered, beautifully-laid-out collections of information, like immaculate giant gardens."

Conclusion(gp): So far, so good

**

Saltzer and Schroeder:
"b) Fail-safe defaults: Base access decisions on permission rather than exclusion. This principle, suggested by E. Glaser in 1965,8 means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation."

Conclusion(gp): A conservative design principle that puts the object's owner in control of permissions. This makes a lot of sense from the object point of view, but does little to address the use case in which it executes.

**

Saltzer and Schroeder:
"c) Complete mediation: Every access to every object must be checked for authority. This principle, when systematically applied, is the primary underpinning of the protection system. It forces a system-wide view of access control, which in addition to normal operation includes initialization, recovery, shutdown, and maintenance. It implies that a foolproof method of identifying the source of every request must be devised. It also requires that proposals to gain performance by remembering the result of an authority check be examined skeptically. If a change in authority occurs, such remembered results must be systematically updated."

Gelernter:
"8. The software systems we depend on most today are operating systems (Unix, the Macintosh OS, Windows et. al.) and browsers (Internet Explorer, Netscape Communicator...). Operating systems are connectors that fasten users to computers; they attach to the computer at one end, the user at the other. Browsers fasten users to remote computers, to "servers" on the internet.

Today's operating systems and browsers are obsolete because people no longer want to be connected to computers — near ones OR remote ones. (They probably never did). They want to be connected to information. In the future, people are connected to cyberbodies; cyberbodies drift in the computational cosmos — also known as the Swarm, the Cybersphere.

13. Any well-designed next-generation electronic gadget will come with a ``Disable Omniscience'' button.

17. A cyberbody can be replicated or distributed over many computers; can inhabit many computers at the same time. If the Cybersphere's computers are tiles in a paved courtyard, a cyberbody is a cloud's drifting shadow covering many tiles simultaneously.

20. If a million people use a Web site simultaneously, doesn't that mean that we must have a heavy-duty remote server to keep them all happy? No; we could move the site onto a million desktops and use the internet for coordination. The "site" is like a military unit in the field, the general moving with his troops (or like a hockey team in constant swarming motion). (We used essentially this technique to build the first tuple space implementations. They seemed to depend on a shared server, but the server was an illusion; there was no server, just a swarm of clients.) Could Amazon.com be an itinerant horde instead of a fixed Central Command Post? Yes."

Conclusion(gp): Complete mediation provides the underpinning for Saltzer and Schroeder's system, but does not appear to scale to the desired itinerant horde at least in common interpretation.

**

Saltzer and Schroeder:
"d) Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical user may be allowed to convince himself that the system he is about to use is adequate for his purpose. Finally, it is simply not realistic to attempt to maintain secrecy for any system which receives wide distribution."

Conclusion(gp): both seem to agree, hard to get the itinerant horde moving in a swarm without open standards.

**

Saltzer and Schroeder:
"e) Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key. The relevance of this observation to computer systems was pointed out by R. Needham in 1973. The reason is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information. This principle is often used in bank safe-deposit boxes. It is also at work in the defense system that fires a nuclear weapon only if two different people both give the correct command. In a computer system, separated keys apply to any situation in which two or more conditions must be met before access should be permitted. For example, systems providing user-extendible protected data types usually depend on separation of privilege for their implementation."

Gelernter:
"37. Elements stored in a mind do not have names and are not organized into folders; are retrieved not by name or folder but by contents. (Hear a voice, think of a face: you've retrieved a memory that contains the voice as one component.) You can see everything in your memory from the standpoint of past, present and future. Using a file cabinet, you classify information when you put it in; minds classify information when it is taken out. (Yesterday afternoon at four you stood with Natasha on Fifth Avenue in the rain — as you might recall when you are thinking about "Fifth Avenue," "rain," "Natasha" or many other things. But you attached no such labels to the memory when you acquired it. The classification happened retrospectively.)"

Conclusion(gp): Information Security models tend to look at things statically through information classification lenses, but its how information is used that makes it valuable. In practice this is how information security theory breaks down in the face of reality - what does an access control matrix look like for a mashup? What does it look like for a data mining app?

**

Saltzer and Schroeder:
"f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle."

Gelernter:
"28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a "passive" instead of "active" view of information management that is fundamentally wrong for computers.

29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be.

30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous."

Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes.

**

Saltzer and Schroeder:
"g) Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users [28]. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user's own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it."

Gelernter:
"6. Miniaturization was the big theme in the first age of computers: rising power, falling prices, computers for everybody. Theme of the Second Age now approaching: computing transcends computers. Information travels through a sea of anonymous, interchangeable computers like a breeze through tall grass. A dekstop computer is a scooped-out hole in the beach where information from the Cybersphere wells up like seawater.

16. The future is dense with computers. They will hang around everywhere in lush growths like Spanish moss. They will swarm like locusts. But a swarm is not merely a big crowd. The individuals in the swarm lose their identities. The computers that make up this global swarm will blend together into the seamless substance of the Cybersphere. Within the swarm, individual computers will be as anonymous as molecules of air.

55. Software can solve hard problems in two ways: by algorithm or by making connections — by delivering the problem to exactly the right human problem-solver. The second technique is just as powerful as the first, but so far we have ignored it.

56. Lifestreams and microcosms are the two most important cyberbody types; they relate to each other as a single musical line relates to a single chord. The stream is a "moment in space," the microcosm a moment in time."

**

Saltzer and Schroeder:
"h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors."

Gelernter:
"7. "The network is the computer" — yes; but we're less interested in computers all the time. The real topic in astronomy is the cosmos, not telescopes. The real topic in computing is the Cybersphere and the cyberstructures in it, not the computers we use as telescopes and tuners.

27. Modern computing is based on an analogy between computers and file cabinets that is fundamentally wrong and affects nearly every move we make. (We store "files" on disks, write "records," organize files into "folders" — file-cabinet language.) Computers are fundamentally unlike file cabinets because they can take action.

31. Our standard policy on file names has far-reaching consequences: doesn't merely force us to make up names where no name is called for; also imposes strong limits on our handling of an important class of documents — ones that arrive from the outside world. A newly-arrived email message (for example) can't stand on its own as a separate document — can't show up alongside other files in searches, sit by itself on the desktop, be opened or printed independently; it has no name, so it must be buried on arrival inside some existing file (the mail file) that does have a name. The same holds for incoming photos and faxes, Web bookmarks, scanned images...

32. You shouldn't have to put files in directories. The directories should reach out and take them. If a file belongs in six directories, all six should reach out and grab it automatically, simultaneously.

33. A file should be allowed to have no name, one name or many names. Many files should be allowed to share one name. A file should be allowed to be in no directory, one directory, or many directories. Many files should be allowed to share one directory. Of these eight possibilities, only three are legal and the other five are banned — for no good reason.

53. Your car, your school, your company and yourself are all one-track vehicles moving forward through time, and they will each leave a stream-shaped cyberbody (like an aircraft's contrail) behind them as they go. These vapor-trails of crystallized experience will represent our first concrete answer to a hard question: what is a company, a university, any sort of ongoing organization or institution, if its staff and customers and owners can all change, its buildings be bulldozed, its site relocated — what's left? What is it? The answer: a lifestream in cyberspace."


**
Conclusion(gp):

The Saltzer and Schroeder principles of Open Design and Economy of Mechanism hold up well in the face of modern computing realities, and to a certain extent Fail Safe Defaults does as well; however if we information security people are to be effective we need to re-think the other principles.

**

Last word: Gelernter:
We'll know the system is working when a butterfly wanders into the in-box and (a few wingbeats later) flutters out — and in that brief interval the system has transcribed the creature's appearance and analyzed its way of moving, and the real butterfly leaves a shadow-butterfly behind. Some time soon afterward you'll be examining some tedious electronic document and a cyber-butterfly will appear at the bottom left corner of your screen (maybe a Hamearis lucina) and pause there, briefly hiding the text (and showing its neatly-folded rusty-chocolate wings like Victorian paisley, with orange eyespots) — and moments later will have crossed the screen and be gone.
]]> Wed, 25 Jun 2008 13:29:25 +0000 protection mechanisms protection mechanisms correctly information security information implements protection mechanisms information travels information security people protection potential information path Mashup of the Titans <![CDATA[Security Briefing: June 17th]]> http://securityratty.com/article/f0d94aeaa6ff8c9f7a5268a0ecd7ad1c http://securityratty.com/article/f0d94aeaa6ff8c9f7a5268a0ecd7ad1c
newspapera.jpg

Sleep deprivation, caffeine overload and documentation. How long till I start hallucinating? Stay tuned.
:)
Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Router-hacking Trojans spotted | Web User News
  2. The ’secret’: Banks are freaked out by security | ZDNet
  3. Malware not man blamed in child abuse download case | The Regsiter
  4. Security Bonuses for Vista Programmers | eWeek
  5. PCI DSS: Section 6.6 gets teeth – finally
  6. IM Security’s Three Kings | CSO Online
  7. Victim of its own success | BBC News
  8. Dacre promises new look at rules on hacking by journalists Guardian

Tags: , , , ,

]]> Tue, 17 Jun 2008 07:33:11 +0000 security web user news news security news information security liquidmatrix security security blog bbc news security bonuses Security Briefing: June 17th <![CDATA[Canadian farmer personal information on stolen CCGA laptop]]> http://securityratty.com/article/59ad7c04243f6352dc04e5847a1515dd http://securityratty.com/article/59ad7c04243f6352dc04e5847a1515dd Security Breach

Date Reported:
6/4/08

Organization:
Government of Canada

Contractor/Consultant/Branch:
Canadian Canola Growers Association (CCGA)

Victims:
Farmers

Number Affected:
~32,000

Types of Data:
"social insurance numbers, bank account numbers and other data"

Breach Description:
"OTTAWA, June 5 (UPI) -- Prairie farmers in Canada are upset the federal government waited two months to tell them a laptop computer containing their personal data was missing."

Reference URL:
Winnipeg Free Press
CBC News
United Press International

Report Credit:
Lindsay Wiebe, Winnipeg Free Press

Response:
From the online sources cited above:

About 32,000 Canadian farmers are on the alert after learning a laptop containing their financial information has been stolen.

The laptop was stolen when a programmer working for the Canadian Canola Growers Association took the machine off-site for routine maintenance.
[Evan] No offense to programmers, but in my experience the ways they use information can be some of the most dangerous threats to information security.  There is no reason for a programmer to EVER have access to confidential production information.  Programmers should only be permitted to work with scrubbed information in a test and/or development environment.

CCGA general manager Rick White described the theft as a classic "smash and grab."
[Evan] Also classic as in another organization that either does not know how or is unwilling to properly secure confidential information.

The laptop has the bank account numbers and social insurance numbers of farmers who applied for Agriculture Canada's advance payments program, which is administered by the CCGA on behalf of the federal government.

Although the theft happened March 30, Canadians weren't sent letters until last week informing them

The federal department has sent letters out to all farmers affected by the theft.

The letter said the laptop was stolen from an undisclosed, remote location in Manitoba.

"We treat this very seriously," White said. "This is an unfortunate incident, a very low-risk one."
[Evan] Mr. White is probably not well versed in risk analysis.  Or incident response for that matter.

the strict security measures being used on the laptop reduce the chances of information being misused, White said.
[Evan] Like what?

"There was a very strong password protection on it, [and] there was a biometric fingerprint reader on it," he said. "That would prohibit anyone other than the user or the person with the password to access the data on the laptop."
[Evan] These are "strict security measures"?  My emphatic answer is NO!  These "strict security measures" are easily bypassed.

but the data was not encrypted
[Evan] The missing piece of the puzzle.  Why go through all of the (self-proclaimed) "strict security measures" and not employ encryption.  What you get with full-disk encryption is pre-boot authentication and this defeats the boot to CD attack.

Agriculture Canada spokesman Sean Malone said there were security features on the laptop, but a sophisticated hacker could likely bypass them.
[Evan] No sophistication required.  A novice could figure it out with Google, a CD, and 15 minutes.

So far, there have been no reports of identity theft among the farmers, the report said.

Pitblado LLP privacy lawyer Brian Bowman said the CCGA and agriculture department deserve credit for notifying people of the breach -- a move not required by Manitoba law.
[Evan] Just because CCGA is not required by law, doesn't mean that they deserve any credit for notification.  The information belongs to the victims not CCGA, and as owners of the information don't you think they should be informed of an incident that has the potential affect them personally?

Victim Reaction:
"If they're devilish enough to steal a computer, maybe they're devilish enough to do something with the information,"

"What frustrates me is that they've treated this like it's no skin off their back,"

"They've known this since then and they're only getting the letters out now?"

"I don't want to find out a mortgage has been taken out on our farm."

Commentary:
It is bad enough for an organization to lose confidential information on a poorly protected laptop, but what makes this more troubling is the apparent fact that they still view the practice that led to the breach as a low risk.  Clueless and sad.

Past Breaches:
Government of Canada:
December, 2007 - Passport Canada web site suffers serious breach
November, 2007 - Service Canada stolen laptop affects more than 1,600

]]> Sun, 08 Jun 2008 15:32:52 +0000 information laptop financial information confidential information laptop affects computer strict security measures ccga laptop computer Canadian farmer personal information on stolen CCGA laptop <![CDATA[Is Microsofts SDL Working?]]> http://securityratty.com/article/365e4bf8f4ca178c1f5548768b8af983 http://securityratty.com/article/365e4bf8f4ca178c1f5548768b8af983

Blogger: Pete Lindstrom

Microsoft’s Security Development Lifecycle (SDL) is the main product of its Trustworthy Computing Initiative, launched from the now-famous Bill Gates memo in 2002. Six years into the initiative, Microsoft surely must be reaping the benefits of, for example, the well-publicized security training every developer went through.

So, how do we determine whether the SDL is working? Microsoft suggests that this is a simple exercise – simply compare the number of public vulnerabilities disclosed for products prior to SDL with similar products developed after SDL. The most recent case was comparing Windows XP SP2 to Vista vulnerabilities in the first year. The count is down and Microsoft provides a quick and easy example of the logical fallacy “post hoc ergo propter hoc” which in this case means “public perception is ripe for deception.”

The biggest problem with Microsoft’s assertion is simply that there are too many variables that are uncontrolled and could just as easily be making the difference. There are too many unknowns related to effort of independent researchers and focus on a specific Microsoft platform. At the very least, Microsoft has done an admirable job in making people feel more secure. (I happen to believe the SDL is working as well, but that belief is a matter of conjecture without strong evidence).

If Microsoft wants to use public vulnerability counts as the ultimate arbiter, it needs to create an environment where independent researchers are encouraged to find bugs. Creating a controlled bounty program for a limited time period would increase incentives and at least provide circumstantial evidence of SDL effectiveness. Interestingly, if the number of vuln counts was higher, it still wouldn’t mean SDL is ineffective,  but the framing of the conversation would be entirely different.

The plot thickens when Microsoft makes claims that spending more time and leveraging external resources are a part of SDL. Whether they are or not, there is a big difference between making programmers more secure developers and simply spending more money on a problem. You don’t really need SDL if the latter is more beneficial.

But if public vulnerability counts are not the answer, what should Microsoft be doing to demonstrate the effectiveness of its SDL? Well, it is much easier to determine causality by controlling for all other variables, and conducting a test of two groups – one with SDL training and one without. Comparing vulnerability creation rates per unit output (either developer-hours or lines of code, for example) would go a long way to answering the effectiveness question.

At this stage, it might be difficult to find a group of developers in-house that aren’t SDL trained, and Microsoft is fully vested in the program such that it wouldn’t allow an untrained developer on a real project, so a new experiment may need to be set up using some arbitrary project created solely for the experiment. Alternatively, Microsoft could measure the differences in development skills after an acquisition and during the transition to SDL-trained developers. Or a final option is to conduct a private benchmarking exercise where the effectiveness is compared among multiple groups.

At this stage, it may be even harder to figure out the effectiveness of an SDL-trained QA group. Presumably, QA training will help the group find more bugs earlier, but if the developers are getting better, then the rate of finding vulnerabilities will go down. There are techniques associated with defect density that could be leveraged to determine this effectiveness level as well.

Creating fewer bugs and finding more bugs early, I believe, are the real expectations of SDL, and finding those numbers would provide much stronger evidence for or against its effectiveness. Not only that, but this information would better frame discussions around ultimate effectiveness of software development: Microsoft is likely to have spent more money than anyone else on its SDL efforts, so the benchmarks provided by the company would serve as an upper limit for expectations.

]]> Fri, 16 May 2008 07:05:09 +0000 sdl sdl efforts sdl effectiveness microsoft microsoft surely specific microsoft platform effectiveness effectiveness level microsoft suggests Is Microsofts SDL Working?