What Is It This Year?

Well, ACSAC 29 is upon us, at the Hyatt French Quarter in New Orleans. userpic=acsacThis has been a crazy conference year. First, due to the shutdown and the uncertainty about budgets, people haven’t registered until the very last minute… making planning very difficult. Today, complicating matters, a weather system hit the midwest. I’m coordinating the training program. Two of my instructors for Tuesday are stuck in Dallas with cancelled flights, and the instructor for Monday coming from Minneapolis is finally getting to New Orleans… after 4 different airports and 12 hours… and he’s arriving after midnight. This is the first year this has ever happened.

Let’s hope this all settles down and the rest of the conference goes better.

P.S.: Also complicating matters is the fallout from those people who have abused conferences, which makes it much much harder for people to attend legitimate technical conferences. This has gotten to the point where even having “Conference” in the name can get you disapproved.


ACSAC Training Program for 2013

userpic=acsacI just realized I never announced the training program for the Annual Computer Security Applications Conference (ACSAC). Let me correct that now, especially as registration for the conference is now open. We have a really great training program this year during the first two days — a program that emphasizes our “hard topics” theme of cyberphysical security. I should note that these courses are in addition to the TracerFIRE forensics training program, the two-day Layered Assurance Workshop, on Monday and Tuesday, and the Next Generation Malware Attacks and Defense Workshop on Tuesday. The courses we are offering on Monday and Tuesday are as follows:

Morning Afternoon
Mobile Security: Securing Mobile Devices & Applications
Mr. David Lindner, Aspect Security
Integrating Security Engineering and Software Engineering
Dr. Antonio Maña Gomez, University of Malaga;
Dr. Ronald S. Ross, NIST;
Dr. Carsten Rudolph, Fraunhofer SIT;
Mr. Jose F. Ruiz, Fraunhofer SIT
Introduction to Reverse Engineering Malware
Dr. Golden G. Richard III, University of New Orleans
Analysing Android Malware at Runtime
Dr Giovanni Russello, University of Auckland
Finding Data Leaks in Applications, Network Protocols, and Systems with Open Source Computer Forensics Tools
Dr. Simson Garfinkel, forensicswiki.org
Authentication & Authorization Standards for the Cloud
Dr. Hassan Takabi, University of North Texas
Cyber-Physical Systems Security
Dr. Alvaro A. Cárdenas, University of Texas, Dallas

This, of course is in addition to the excellent technical program we have the remainer of the week. In addition to the cyberphysical security focus, we’re going to have special tracks dealing with system security engineering (our National Interest topic), and loads of great speakers and panels. I’ll note that I’ll be chairing and participating in a panel that is looking at the Legacy of the TCSEC after 30 years, and you don’t want to miss that!

Some come join us in New Orleans the week of December 9. Move your theatre tickets if you have to (we did). This conference is a great way to keep up to date technically, and we’ll provide you with a certificate you can use to support your CISSP CEU claims.


Musings on a Book of Orange

userpic=securityLast night, I wrote on Facebook that I had been invited to talk at ACSAC about the legacy of the “Orange Book” (TCSEC), as 2013 marks 30 years since it was first published. I was fishing for opinions from a number of people whom I respect (but I’d take them from folks I don’t respect as well 🙂 ), but got few response. So let me expand on my current thoughts… perhaps this will get folks thinking.

The TCSEC was a seminal publication in security … one of the first security criteria out there. It defined preset grouping of functionality and assurance requirements (what today we would call a package or a profile) that were well thought out. This was a strength, but it was also a problem as the pre-defined packages didn’t work well for anything other than monolithic operating systems. The assurance paradigm that it had was based on in-depth design analysis — increasing the level of design details and analysis, as well as testing, to ensure all problems were found.

How well did this all work out? Well, there was the mantra of “C2 by ’92”, which admittedly got more and more systems to have discretionary access control, object reuse, auditing, and I&A. This was one of the factors that led to Windows having more security — NT had to have stronger security to meet C2 by ’92, and Windows NT is the basis of today’s Windows systems. Could one argue that the TCSEC beat up Windows 98 in an alley fight? Perhaps.

However, the assurance paradigm was in some sense flawed, and may have gone down the wrong path. There was a naive assumption that if we could get commercial vendors to follow that path, we would have more secure systems. Did that work? Those working with evaluated systems can answer that question — we never saw higher assurance take off, because it went against commercial practice.

The chafing against the pre-set packages of the digraphs also led to an unbundling of functionality of assurance, eventually leading to the Common Criteria of today. I’d argue that this eventually gave us the “control” notion we now see in 800-53: pick the functional and assurance requirements you need to meet your threats. This is a good thing, but it is also a loss of the forethought that went into the bundling. We are seeing a return to bundling in some sense with the move to standard protection profiles and  CNSS 1253 baselines and controlled ways to modify things. Did the TCSEC show the value of these bundles?

The TCSEC, just like 800-53 and the CC, is a catalog of requirements; it is not an evaluation process. Yet the evaluation process that grew up around the TCSEC also has a legacy. That process established a very in-depth process that took far too long. The legacy of that process — and the analysis the TCSEC required — affected how the process is viewed today. We’re still seeing fights against a process that takes too long, and we still haven’t found the balance between better / faster / cheaper that is satisfactory for both the vendors and users of evaluated products.

I’d like to think that the TCSEC has a greater legacy than just perl. Hopefully, my preliminary thoughts above have gotten you thinking, and you’ll share your thoughts in the comments. I’m going to keep thinking on this so that I can work all of this together into a coherent presentation.


Additional musings added a few days later:

Thinking more about the TCSEC, I’m seeing a number of dimensions of impact (think like a tag cloud), other than (of course) perl. Here are some thoughts on each in alphabetic order — feel free to add more in the comments:

  • Assumptions. Familiarity with the TCSEC led to assumptions about functionality that didn’t propagate through to newer criteria. One can see this in the Common Criteria. Notions that were present in the TCSEC — such as protecting authentication data or having process separation — are no longer explicit in the CC. People assume they are there, but they are not. Are they tested for? 
  • Assurance. The TCSEC codified the notion of design assurance, but most people didn’t see design assurance because they didn’t see above C2. Although the design assurance transferred to the Common Criteria (CC), there it was more of a failure — precisely because it never became commercial practice for the vendors. Instead, documentation was developed after the fact, which doesn’t improve assurance. Today, is there more thought given to making the design small, simple, and minimized… or are things large and complex with multiple failure paths? Did the TCSEC avenues to assurance survive?
  • Awareness. Did the TCSEC make people more aware of security? Certainly, those working on the government side know what C2 security is — if only in terms of the functional requirements. But people in general? Most people probably don’t understand access control or audit — they never use the DAC mechanisms in Windows or Apple, and they’ve probably never looked at the event log. To most people, security is Passwords.
  • Bundling. One characteristic of the TCSEC is it bundled functions with assurance. This was also its downfall, as the bundling was designed for a monolithic world and assumed MLS was a need. Yes, MLS needs high assurance, but high assurance doesn’t demand MLS. That was a failure, and that notion led to the unbundled CC. But bundling is returning with the new standard Protection Profiles, the -53 baselines, and overlays. There is thought being given to what requirements belong together. This is good. The problem is there’s often no thought about what these requirements need in terms of assurance. Assurance is typically “best possible” (the standard PP approach), which doesn’t necessarily correspond to what the functions need in their environment. We’re still faced with the eternal problem: people don’t pay for invisible assurance.
  • Commercial Products. In my earlier part of this post, I argued that the TCSEC improved the security of some commercial products. Certainly it influenced Windows NT, and arguably influenced a number of Unixes, although whether any of those made it into the Unix base of today is a different question. But many products still think about security after the fact, or don’t incorporate it into the design process.
  • Confidentiality. The TCSEC’s focus was confidentiality — access controls to prevent disclosure. This focus remained for many years, and might have hurt trying to grow the focus to integrity and availability.
  • Controls. Did the TCSEC come up with the “control” paradigm, or did that exist in the financial world before 1983? Certainly the TCSEC began the Federal Criteria which begat the CC, and TCSEC requirements and CC requirements influenced the controls in NIST SP 800-53.
  • Developmental Assurance. The TCSEC had the notion that a well-thought out design would lead to a higher assurance product. Has that been borne out, or is it like FDA studies of marijuana? Is there empirical evidence of what design approaches do best, and did that agree with the TCSEC? Did commercial vendors ever actually follow the TCSEC processes?
  • Formal Methods. The TCSEC pushed the notion of formal methods at the higher levels. Yet we rarely see formal methods these days.
  • Government Development. Here the TCSEC had more influence. The notion of C2 by 92 led to pushes to use C2 functionality, and this was captured in the 8500.2 controls and 800-53 controls. Many of the security requirements for systems today come from C2. However, the focus on functionality led to a loss of focus on assurance, and that’s only lately being recovered. There was also the assumption problem above.
  • Multilevel Security. The TCSEC envisioned a world where MLS was everywhere. Yet MLS as a concept disappeared, reappeared under different names, and nowadays is present mostly in specialized guarding devices. Its become a dirty word — is that because of the TCSEC?
  • Product Evaluation. The TCSEC showed the value that could come from product evaluation in the overall accreditation process. Countless dollars were saved because operating systems and other products did not need to be reexamined in depth. Yet the original process in the US (TPEP) was very expensive for the government and took a lot of time. Think “Better / Faster / Cheaper”. We moved to a cheaper process of having labs do the work. People still complained it wasn’t faster. The CC came in, and we’ve been tinkering with the process to make it faster and faster because of Internet time scales. Have we made it better than we had it during the TCSEC? Are the requirements as well understood today? How did the legacy of the TCSEC process color today’s process.

These are just some areas. Perhaps as we explore the legacy, there should be an additional question asked: For those areas where the legacy shows a form of failure, are there places were we can learn lessons and perhaps improve where we are today. Given I’m dealing with the TL;DR generation, perhaps that should be a topic for a future post … or ACSAC talk.



Saturday Clearing O’ The Links

userpic=observationsIt’s Saturday, and you know what that means — time to clear out those links that couldn’t form into a coherent theme over the week. That doesn’t mean this are incoherent links, but … umm … perhaps we should just get to the links:

  • Theatre Stuff. This has been a busy week theatre-wise — based on some good reviews in the times and some timely discoveries, I’ve now filled out my June theatre dance card. You’ll see that in tomorrow’s review of Priscilla, but I do have a few theatre items. First is a very interesting review of Scottsboro Boys at the Ahmanson… written by a resident of Scottsboro AR. His take is very different than some. Second, I’ve become a tag at Bitter Lemons! Perhaps I should explain: Bitter Lemons is a theatre site here in Los Angeles that aggregates reviews and writeups of local shows, and then uses them to ascribe an overall “lemon” score — from sweet to bitter — on each show. They evidently like my writeups enough to include them in the meter, and I’m honored by that inclusion. I’ve even more honored that Colin, who runs the site, wrote a wonderful response to a post I did a while back regarding critics and their place. I also really liked their advice to the aspiring critic; I’ll take a number of those items to heart. A PS to the good folks at REP East: You should pay attention to this post about getting your shows in the Lemon Meter.
  • Your Net Worth. Two different posts looks at the question of what you are worth to different groups. Yes, you. First, have you ever thought about who was the most valuable patron to a casino: a pennyslot player or a blackjack player. The answer may surprise you – the pennyslot player. What about on Facebook? How much are you worth if you “like” something? Read this post, and you’ll be very hesitant about “like”-ing in the future.
  • The State of Affairs. A couple of state things. First, an interesting map that shows if you are in “dog” or a “cat” state. This is based on the percentage of pet ownership of each type. I’m in a neutral state, it seems. What I’d love to find is a map that categorized cities as “east coast” or “west coast” — and this isn’t a geographical distinction. Perhaps one day I’ll explain it, but I’ll give my two favorite examples: LA and KC are “west coast”, San Francisco and St. Louis are “east coast”.  Second, the city hall in St. Louis is slowly deteriorating, and no one is doing anything about it. It’s not that St. Louis doesn’t have city pride; it’s that they don’t associate it with their city hall.
  • Conference Concerns. I’ve been involved with the ACSAC conference for many years (in fact, training submissions are still open — you have until Monday to get something in). Thus, I’m worried whenever incidents such as the recent IRS boondoggle hit the news — it makes people start seeing conferences as frivolous. It also leads to bills such as those mentioned in this article, that would ban travel to “fun” places. Conferences can be useful and cost effective, if GSA guidelines are followed and the organizers focus on technical content and quality. As always, perception is everything. The important thing to remember is electronic interaction cannot replace face-to-face interaction, just like recommendations from Amazon cannot replace browsing at the bookstore.
  • An Interesting Kickstarter. The SCGD mailing list alerted me to an interesting Kickstarter: A group of gamers is attempting to start a Board Game Cafe in Glendale CA. I love the idea, but I’m less sure about the location — I think it would do better in Westwood (near UCLA) or Northridge (near CSUN). Still I may decide to support them. Basically, the idea is as follows: customers visit the café and for a small cover charge they get access to an extensive board game library (which often runs into hundreds of titles) as well as food and drink options from the café. There is no establishment like this in Los Angeles. There are game shops, but that’s a different atmosphere. The question is: Will it be a destination? It might — after all, they have pie. (All I know is the pie sold me — I’m a supporter. Please help them make their stretch goal so I get pie!)

Music: Folk Era Mini CD (The Kingston Trio): “Tom Dooley”


ACSAC 2012 Last Day / Friday Fun

ACSAC Last Day:

Today was the last day of ACSAC. Had a great session on Continuous Monitoring from Ron Ross. That was followed by an even greater panel session with me (on Collaborative Protection Profiles), Mike McEviley (on System Security Engineering), and Ron (well, supposedly on Overlays, but he never got to that topic).

After the end of ACSAC, got the office packed up (as I usually do), and got all the boxes shipped (as I usually do, educating FedEx Office along the way).

Friday Fun:

After the conference, we went to the Charles Hosmer Morse Museum of American Art. This is a really cool museum in Winter Park with loads and loads of Tiffany glass — lamps, windows, and other stuff. Dinner was at a great Turkish restaurant, Bosphorous. Now we need to find Turkish food in LA (hmmm, there may be some place in Reseda). Tomorrow… Epcot!

ETA (while I’m waiting for a download to finish): Winter Park is a really neat Orlando community. Hipster neighborhood, with lots of funky stores and restaurants. Loads of ethnic cuisine, art stores, and such. A very different image of Orlando than the touristy places where we are staying near Downtown Disney.

Friday Un-Fun:

When we got back to the hotel, we got in the elevator to go to our room. Around the third floor (we were on the fifth), a jerk and… nothing. We were stuck in the elevator. After about 15 minutes, we were freed (they are comping Sunday morning breakfast… which happens to be the Character brunch!)

After that, I logged into work. Someone at work is trying, on Friday, to schedule a meeting at 5pm Pacific on Tuesday. That doesn’t fly for me, and probably flies even less well for folks on the East Coast.  Sigh. I’ll likely have to do some work Monday from home.

ETA #2: The hotel is filled with a pre-teen cheerleaders convention, as well as a bunch of Pop-Warner boys (and a bunch of medical coders, but they are OK). First, I feel like Miss Hannigan from Annie: “Little girls, little girls, everywhere I look I see them”. Second, I start to realize I’m in “Get off my lawn” mode, especially when the kids are noisy in the hall or in the pool that faces our room. Sigh. Another demonstration I’m getting older.


ACSAC Update #2

I’ve been a busy busy boy at the conference. A few highlights before I go to bed…

  • Ron Ross gave a very good opening keynote, made even more amazing when you realize he did it with a major toothache.
  • Marshall and I ended up doing the tutorial. It was very well received. Want to see it? Come to GSAW 2012!
  • Last night, Ross Anderson gave a great talk on the economics of computer security. If I was 20 years younger, I might be interested in research in that field.
  • The Conference Dinner was delightful. I had a wonderful conversation with the folks from @sec; there was also some great conversation with some grad students from UC Riverside.
  • This morning I went to Ron’s talk on -53 Revision 4. Good talk.
  • This afternoon I went to an excellent panel on software assurance. Got to see Kris Britton — haven’t seen Kris in years!
  • This afternoon’s talk by Eran Feigenbaum of Google on Cloud Security was also very very good.
  • Tonight was the conference committee dinner at a Brazilian restaurant. I’m stuffed.

One more morning, and ACSAC 2012 is over. ACSAC 2013 in New Orleans!


ACSAC 2012 Update #1

Well, the two training days of ACSAC (for which I am responsible) are over. I was able to audit three excellent sessions: one on Security Requirement Engineering, one on Assurance (which ended up having a greater focus on Mission and System Security Assurance), and one on Resilience. Good speakers, great subject material — this is what I love to see in ACSAC training sessions. I also had some great conversations over lunch and at the reception tonight regarding a myriad of technical subjects. Now if I can just avoid the ACSAC 15 (like the Freshman 15), I’ll be fine.

Tomorrow, some excellent technical sessions, plus I get to condense a 6 hour tutorial into perhaps 5!


Arrived in Orlando

This is just a quick note to left folks know that I’ve arrived in Orlando FL for ACSAC. Dinner was in Downtown Disney at Raglan Road (yum), and now it is quickly catching up on the nets. Tomorrow…. the conference starts!