[00:06.220 --> 00:15.340]  Good morning and welcome to day two of H2K2 starting off nearly on time here in track B.
[00:15.740 --> 00:17.980]  I hope everyone's having a good conference so far.
[00:18.100 --> 00:19.420]  I'm sure there's some people that just arrived.
[00:19.420 --> 00:23.020]  We had an action-packed and very fun day yesterday.
[00:23.160 --> 00:23.960]  At least it was fun for me.
[00:24.060 --> 00:25.260]  I'm sure it was fun for a lot of people.
[00:25.850 --> 00:27.900]  Had a pretty good overnight.
[00:28.420 --> 00:33.320]  Not as many people as I might have guessed hanging around on the second floor, but pretty good.
[00:33.500 --> 00:34.000]  A lot of music.
[00:34.520 --> 00:36.780]  People wandering the streets and that sort of thing.
[00:37.520 --> 00:48.220]  And so far it's been a very peaceful conference and very responsible and I think very informative for a lot of people who are trying to keep that trend going throughout today.
[00:49.140 --> 00:51.520]  So I'll do my self-introduction here.
[00:51.640 --> 00:55.280]  My name is Greg Newby and you've seen me running around a little bit.
[00:55.420 --> 01:02.240]  I'm doing a few other things at the conference over the weekend and managed to give a talk yesterday and sit on a panel.
[01:02.240 --> 01:05.980]  And this talk actually is completely separate.
[01:06.140 --> 01:08.720]  There's almost no overlap with the stuff I talked about yesterday.
[01:09.520 --> 01:20.160]  The impetus for this talk really is that I see so much very, very poor security in the physical world.
[01:20.160 --> 01:23.080]  just poorly implemented, poorly thought out.
[01:23.500 --> 01:30.280]  Where really I look and I say, well, it wouldn't take a whole lot of just a little feedback loop to really improve that a whole lot.
[01:30.400 --> 01:35.480]  And of course you have to question while you're thinking about that, well, maybe this is intentional.
[01:35.600 --> 01:39.380]  Maybe it's just not worth it to spend the extra effort, spend the extra time.
[01:39.380 --> 01:44.820]  But the thing I want to address, because we'll talk about the risks and cost-benefit analysis.
[01:45.220 --> 01:57.880]  But the thing I want to address is, what if we changed our mindset in the physical world with physical security or non-computerized, essentially, security to be where our minds already are in the computerized world?
[01:57.880 --> 02:10.280]  Because for the most part, we know, people in this room know, that security through obscurity is not effective in the long run, certainly, and often even in the short run in computerized systems.
[02:10.500 --> 02:18.340]  So as I said, the impetus was looking at the mess of security in the physical world and saying, well, maybe we can do some transference.
[02:18.390 --> 02:21.230]  A lot of the time we do transference from the physical world to the computerized world.
[02:21.300 --> 02:23.110]  Maybe this is an opportunity to go back the other way.
[02:23.110 --> 02:27.390]  So it's actually a fairly simple idea, which I just described to you.
[02:28.520 --> 02:32.900]  But I'll work through some of the logic and give you some examples and some thoughts on that.
[02:33.050 --> 02:37.710]  And what I'd appreciate hearing from you is if this just sounds completely ridiculous.
[02:37.790 --> 02:42.170]  Because maybe there are good examples that I'm not thinking of where there should be more obscurity.
[02:42.390 --> 02:50.290]  And maybe there are good examples of where sort of this open model that I'm thinking of has been applied to the physical world.
[02:50.290 --> 02:55.140]  But I'll give you the argument and you can judge for yourself and we can talk about it a little bit at the end.
[02:55.740 --> 02:57.040]  So anyway, my name is Greg Newby.
[02:57.170 --> 03:05.730]  As I said, I am actually a faculty member in the School of Information and Library Science at the University of... I'm stuttering a little this morning...
[03:05.730 --> 03:08.680]  The University of North Carolina in Chapel Hill.
[03:08.900 --> 03:10.600]  And I've been there for about six years.
[03:10.790 --> 03:13.020]  So I was at Illinois before that.
[03:13.180 --> 03:16.360]  I teach all things dealing with information science.
[03:16.360 --> 03:18.340]  I also have a course in information security.
[03:18.820 --> 03:21.020]  I've done internet courses for a long time.
[03:21.180 --> 03:25.100]  I have a course in sort of Unix and Linux systems administration.
[03:25.320 --> 03:30.230]  Do some work with large-scale open-source information retrieval systems.
[03:30.510 --> 03:32.290]  Essentially web search engines.
[03:32.920 --> 03:35.820]  And a lot of other kind of geeky stuff like that.
[03:36.460 --> 03:39.700]  And I'll actually have a slide at the end that has my email.
[03:39.700 --> 03:43.480]  And I'd sort of love to hear from people that have comments on this.
[03:44.980 --> 03:47.600]  So what we're talking about is security through obscurity.
[03:47.900 --> 03:55.620]  And I think to most of the H2K2 conference community, security through obscurity is something that we recognize.
[03:55.800 --> 03:57.670]  We more or less know what we're talking about here.
[03:58.100 --> 04:12.640]  With a lot of the arguments, which we'll talk about briefly in a few minutes, for open-source software, we compare open-source to Microsoft or Oracle or something like that, where you don't get to see the source code.
[04:12.840 --> 04:26.120]  And we say, well, in the open-source, whatever the security model is available for scrutiny by really anybody that wants to, but certainly by experts that might have a particular drive or motivation or desire or skill.
[04:26.120 --> 04:35.240]  And then if you don't have the source code, well, what we're doing is we're obscuring whatever the security problems are by making the source code unavailable.
[04:35.300 --> 04:39.060]  But we are making those security problems go away or making them more difficult to find.
[04:40.240 --> 04:53.420]  So security through obscurity is really something that can work and certainly does work kind of in the short term, except it doesn't actually improve your invulnerability to various types of attacks.
[04:53.420 --> 04:56.200]  All it does is it makes those attacks harder to discover.
[04:56.470 --> 04:59.500]  And we'll talk more about the source code analogy a little bit later on.
[04:59.620 --> 05:03.540]  So like I said, I think this is a fairly common notion for a lot of the conference attendees.
[05:04.350 --> 05:11.040]  We can get a false sense of security by having obscurity because we think, well, it's secret, therefore it's good, right?
[05:11.170 --> 05:15.300]  But that doesn't necessarily, you know, impact the actual procedure that we're using.
[05:15.380 --> 05:21.440]  And what I'm really talking about today is making the procedure good, so good, in fact, that it doesn't need to be secret.
[05:23.800 --> 05:27.600]  If we're obscure, we have a limited ability to verify.
[05:27.920 --> 05:32.900]  So let's say, again, we'll use a lot of software examples, but what I really want to do is make the transcripts, right?
[05:33.180 --> 05:48.160]  Let's say you're a company, you're buying some software, they don't give you the source code, then you have more difficulty, if you wanted to do like a code audit, you have more difficulty in trying to assess the vulnerability than you would if you had the code to augment that assessment.
[05:48.360 --> 05:57.540]  Maybe the code, you know, people that have looked at code for complex systems know that it's a very large task to look at thousands and thousands of lines of code and say, aha, there it is.
[05:57.660 --> 06:02.520]  I just saw the, you know, there it is on line 10.22, I just saw the vulnerability.
[06:02.520 --> 06:04.020]  I mean, certainly that does happen sometimes.
[06:04.260 --> 06:06.680]  But the openness, the open source does help.
[06:06.800 --> 06:13.780]  And having, of course, more openness, open standards, being in on the discussions and the design and so forth can help as well.
[06:16.000 --> 06:20.760]  And again, with the vulnerabilities, who's going to look for these vulnerabilities?
[06:20.760 --> 06:26.120]  If we have an obscure system, let's do a physical one, let's say a bank system, right?
[06:26.260 --> 06:30.720]  A bank vault, you know, bringing the money in and out, having security guards and stuff like that.
[06:31.000 --> 06:41.480]  Well, and I'm not necessarily saying that all of the everything, you know, like the accommodation to the bank and the security guard's home address and their work schedule and stuff should be open for scrutiny.
[06:41.480 --> 06:44.960]  What I'm going to say is that maybe secrecy should be a part of the model.
[06:46.620 --> 06:48.260]  But let's think of a bank.
[06:49.020 --> 06:52.720]  Who is it that's going to study that bank and try to discover their vulnerabilities?
[06:53.860 --> 06:58.180]  Well, you know, interested hobbyists and, you know, bank geeks or whatever.
[06:58.420 --> 07:01.660]  But the people we need to worry about are the criminals, right?
[07:01.900 --> 07:15.860]  And whatever is obscure to someone just kind of walking and doing their banking business is probably not going to be nearly as obscure to someone that wants to spend the effort and the time and has the motivation and possibly the criminal intent and the,
[07:15.860 --> 07:19.240]  you know, money incentive and stuff like that with the bank to study it.
[07:19.340 --> 07:22.260]  So that's where the obscurity doesn't get you much.
[07:22.260 --> 07:24.320]  It buys you time, right?
[07:24.540 --> 07:27.760]  And certainly it can be a component of the security model.
[07:29.060 --> 07:31.980]  But the obscurity itself, I don't think, does that much for you.
[07:35.120 --> 07:41.340]  One of the things that we'll touch on a couple of times this morning is the notion of the insider, the inside attack.
[07:41.340 --> 07:52.440]  And in fact, in everything from banks to businesses, stores, stuff like that in the physical world, and we even hear about this with things like airport security and stuff like that, it's the insider.
[07:52.680 --> 08:04.060]  It's someone that knows the model, someone who's penetrated the obscurity, who is often the person who's the perpetrator or the, you know, whatever vandal or whatever it is they're not supposed to be doing.
[08:04.720 --> 08:09.200]  The outsider has difficulty in unveiling that obscurity.
[08:09.420 --> 08:12.840]  The insider has greater ease in unveiling obscurity.
[08:13.040 --> 08:15.080]  So once again, we have this failure of obscurity.
[08:15.320 --> 08:18.040]  You know, the obscurity doesn't help us really in that situation.
[08:18.040 --> 08:29.980]  What we'd rather have is a process in which knowing about almost everything or everything about how this system works doesn't make the process any weaker.
[08:30.200 --> 08:32.780]  If that's the case, you got yourself a good process.
[08:33.060 --> 08:36.760]  And we'll mention, in addition to open source, we'll talk about crypto.
[08:37.000 --> 08:39.020]  And that's it in crypto, right?
[08:39.340 --> 08:45.500]  In crypto, you don't have security until your procedure has been examined very, very closely.
[08:45.500 --> 08:51.340]  And even then, the crypto experts, the, you know, cryptologists, they won't say 100%.
[08:51.340 --> 08:52.600]  They'll say, well, it seems pretty good.
[08:52.800 --> 08:55.260]  You know, but there might be other things we haven't discovered.
[08:55.620 --> 09:01.240]  So I'm going to put that up as another example of in the digital world where maybe we can learn something in the physical world.
[09:01.360 --> 09:08.800]  So we have some examples of obscurity in place and just, you know, a quick list of common things.
[09:08.980 --> 09:12.600]  We have lockpicking panels here, of course, at H2K2.
[09:12.600 --> 09:22.980]  You might not know, though, that the lockpicking at H2K2 is less than the lockpicking presence at HAL 2001 last year across the pond in Holland.
[09:23.220 --> 09:24.260]  Why do you suppose that is?
[09:25.100 --> 09:27.160]  Laws here about owning lockpicking?
[09:27.320 --> 09:28.340]  Exactly, exactly.
[09:28.500 --> 09:30.920]  You're not even allowed to own lockpicking tools.
[09:31.200 --> 09:32.920]  In some situations, you can own them.
[09:32.920 --> 09:33.880]  In some situations, you can't.
[09:34.080 --> 09:35.080]  There's actually another reason.
[09:35.360 --> 09:37.920]  In Europe, lockpicking is a sport.
[09:38.260 --> 09:39.280]  Yeah, yeah.
[09:39.360 --> 09:41.940]  Well, it would be a sport here, too, if you could do it, right?
[09:42.760 --> 09:43.200]  So...
[09:44.460 --> 09:44.900]  But...
[09:48.650 --> 09:49.090]  Right.
[09:49.710 --> 09:49.770]  Right.
[09:49.950 --> 09:49.970]  Right.
[09:49.970 --> 09:51.090]  The company at HAL also.
[09:51.190 --> 09:51.630]  Yup.
[09:52.170 --> 09:52.410]  Yup.
[09:52.530 --> 09:53.410]  And a lot smaller presence.
[09:53.570 --> 09:56.430]  And we actually spoke with them because I'm on the steering committee for the group.
[09:56.550 --> 10:01.470]  The lockpicking group that was at HAL and was at H2K is going to be back here at H2K2.
[10:01.470 --> 10:06.470]  And they are interested in sitting around and showing people how to do stuff.
[10:06.730 --> 10:13.710]  But they're also concerned about it because they know that there's often a fine and kind of unclear line between what's permitted and not permitted.
[10:14.330 --> 10:15.510]  But anyway, that's just an example.
[10:15.650 --> 10:18.550]  Other examples include the idea that you have cell phones.
[10:18.550 --> 10:30.070]  And instead of having cell phones which are reasonably secure or certainly more secure like they have with the GSM phones, instead we make it illegal to operate a scanner or to purchase a scanner in the U.S.
[10:30.110 --> 10:31.530]  that picks up the cell phone frequencies.
[10:33.410 --> 10:34.690]  It doesn't help, right?
[10:34.930 --> 10:48.510]  And the people that you'd like to stop, which are the people that might be having some sort of criminal intent or some sort of malicious intent, what do they care if they mod their scanner or if they get a scanner from overseas or what have you?
[10:49.070 --> 10:50.310]  That was their intent.
[10:51.790 --> 10:59.330]  Stores, of course, I think are pretty common where you know that there's probably someone watching to make sure you don't steal stuff.
[10:59.330 --> 11:02.350]  But you don't really know are those cameras on or they're tagged.
[11:02.490 --> 11:03.550]  You might know or you might not know.
[11:03.630 --> 11:05.450]  Are there tags on a garment and stuff like that?
[11:06.270 --> 11:07.610]  And we'll see...
[11:07.610 --> 11:13.010]  I bring up stores a couple of times because we'll see that a lot of the times there's this cost-benefit thing, right?
[11:13.330 --> 11:17.570]  Yes, we could put tags on every single, say, garment or every single item in a store.
[11:17.790 --> 11:23.490]  We can make sure we have several cameras, security people at the door, check your bag, stuff like that.
[11:23.690 --> 11:24.470]  We can do this.
[11:24.550 --> 11:25.610]  And in some stores they do.
[11:25.790 --> 11:28.290]  Electronic stores, computer stores a lot of the time, right?
[11:28.290 --> 11:31.470]  But there's a cost associated with doing all that.
[11:31.630 --> 11:39.590]  Not only the cost of the personnel and the equipment to run that type of system, but also the cost of upsetting the person that's your patron.
[11:39.950 --> 11:42.970]  So we'll talk about cost-benefit trade-off.
[11:42.970 --> 11:57.690]  And I think that in stores there's often a pretty conscious decision, or at least a decision that was made someplace that, you know, yeah, we can do better, but we're okay with the level of loss for our level of cost.
[11:58.290 --> 12:00.110]  In airports you just don't know, right?
[12:00.150 --> 12:05.970]  You can't even ask a lot of the time questions, simple questions like, can this go on the plane?
[12:06.090 --> 12:07.050]  Can that not go on the plane?
[12:07.150 --> 12:07.790]  Can I go over here?
[12:07.870 --> 12:08.490]  Can I go over there?
[12:08.490 --> 12:10.790]  You just have to do it and find out that you're in the wrong.
[12:11.850 --> 12:15.110]  And I... we're not going to talk about airports, but I think they're actually not much.
[12:15.230 --> 12:20.910]  Anyway, I think they're very easy to pick on, because they literally do such a poor job of...
[12:21.510 --> 12:36.350]  of meeting the needs when we'd like to at least think or hear that the risk is so high and the cost already is so high in terms of inconvenience, security, and stuff like that, that in exchange If we can arrange for all that effort, we should have a very high level of security.
[12:36.750 --> 12:39.290]  And in fact, as we know, it's not so good, right?
[12:40.970 --> 12:42.550]  Okay, and access to facilities.
[12:42.870 --> 12:46.090]  We'll talk about an example with the conference.
[12:46.350 --> 12:56.090]  So there's just some examples of where I think there's a strong, obscure component to the basic, you know, what do we have for security?
[12:58.410 --> 13:00.350]  So we want to make systems more secure.
[13:00.490 --> 13:04.690]  We're going to try to talk about non-digital systems, although I'll give a couple more digital examples.
[13:05.610 --> 13:07.710]  And we'd like a bunch of different things.
[13:07.910 --> 13:14.750]  And, you know, some of the key words, verification, trust, we want to have some sort of data integrity or verifiability.
[13:14.990 --> 13:23.530]  We want to have non-repudiation, which in the, you know, digital world is about, you know, digital signatures and stuff like that.
[13:23.690 --> 13:32.170]  But in the analog world, in the physical world, we can say, hey, we know that you were or you weren't in that location at that time.
[13:32.170 --> 13:35.210]  So you might or might not have been the perpetrator.
[13:37.010 --> 13:45.510]  And, you know, sort of working through the assurance, trying to reassure ourselves that what we think we have is what we have and that we can verify.
[13:46.650 --> 13:48.930]  And an example here, levels of security.
[13:49.090 --> 14:04.270]  People in this audience are probably familiar with the DOD orange book, the thing that gives the ratings of, you know, C2 and C1 and D2 and D1 and so forth for security clearances or security sort of authorizations of computer systems.
[14:04.270 --> 14:06.170]  And that's now, of course, pretty well outdated.
[14:06.410 --> 14:14.810]  We have a talk, I think it's today, with the open source security model that I'm excited about because we need better models for assessing digital systems.
[14:15.030 --> 14:17.770]  But anyway, the orange book is something that you're likely to have heard of.
[14:17.770 --> 14:25.650]  And what they have there is basically something where the effort or the cost goes up and the security goes up.
[14:25.650 --> 14:42.210]  And people that are interested in a system, let's say a government organization or a school or a business, can say, alright, as I go up this scale and get more and more security in the orange book levels or, you know, other types of systems that you might use to grade your security,
[14:42.770 --> 14:45.450]  my costs go up because it costs more to run it.
[14:45.490 --> 14:47.530]  I might have to have dedicated security personnel.
[14:48.170 --> 14:50.450]  The actual software, hardware might cost more.
[14:50.450 --> 14:56.830]  I'm dedicating more of my hardware and disk space and stuff to doing things like logging and all that sort of thing that happens at the higher levels.
[14:57.010 --> 14:59.370]  And so you make a decision, is this worthwhile?
[15:01.410 --> 15:08.790]  And actually, let me mention, because at the top of the orange book, and a lot of people misunderstood this, I misunderstood it when I first saw it, is the A-levels.
[15:08.870 --> 15:18.150]  And at the A-level, what happens is you have what they call a logical proof that there is security.
[15:18.150 --> 15:22.690]  So it's not that it's assurance, but it's not that someone tells you this is okay.
[15:22.990 --> 15:39.510]  It's that you can actually sit down with like a, you know, a logic system, you know, using, you know, logical mathematics and symbolic notation and stuff, or some other method, and prove to yourself that what you don't want to happen couldn't happen.
[15:41.490 --> 15:50.630]  So we do have some pretty good models, and I think really some very good models in the security world of the digital world, the digital side, for assessing security.
[15:51.370 --> 15:56.270]  And as I said, obscure systems are not really made stronger through their obscurity.
[15:56.410 --> 16:01.650]  They're made possibly more difficult or more time-consuming to identify the vulnerabilities.
[16:01.870 --> 16:04.670]  But the vulnerabilities are still there in most cases.
[16:04.830 --> 16:13.710]  And I think what I'll do is a little bit of a hard line to make, but we're going to talk about secrecy as being maybe a worthwhile component of a security model.
[16:13.710 --> 16:21.230]  And on the other hand, saying obscurity is a problem, and of course, obscurity and secrecy are, you know, really essentially the same thing we're just talking about.
[16:21.550 --> 16:24.310]  One with admiration, the other one with disdain.
[16:24.770 --> 16:41.970]  But I think the idea is, is your procedure in place such that the secrecy fits in with the whole procedure, and you can assure yourself that yes, this is good, versus do you have really no assurance and not much of a procedure, and all you can do is hope that no one finds out whatever your procedure is,
[16:42.110 --> 16:42.750]  right?
[16:42.750 --> 16:48.590]  So I hope that's not too difficult to use those two words there, but I think it's kind of realistic.
[16:49.390 --> 17:04.750]  So the alternative, of course, is something like we have an open source to do scrutiny by personnel, individuals, hobbyists, whoever, really anybody, might be able to find a vulnerability, okay?
[17:04.750 --> 17:21.490]  Yes, in the crypto world, a lot of the time, the cryptologists that are looking at the algorithms and stuff like that, they're pretty highly trained, have a lot of mathematics, have a pretty strong background, and might work in teams and follow procedures.
[17:21.730 --> 17:23.430]  So these are, you know, professionals and experts.
[17:23.630 --> 17:38.710]  But that doesn't mean that a non-professional, non-expert, couldn't find a problem as well, and certainly with a lot of the computer bugs that we hear about and found by, you know, people with some level of expertise, but they're not, you know, they're not necessarily professionals,
[17:38.750 --> 17:43.530]  people that would be, you know, whatever, contracted out or hired to do a security assessment.
[17:43.730 --> 17:45.210]  So I think the more the merrier.
[17:45.410 --> 17:48.550]  The more people that are looking at a security model, the merrier.
[17:48.550 --> 17:51.490]  And there might, as I say, there might be trade-offs, there might be reasons not to do that.
[17:52.390 --> 17:54.990]  And we'll give two examples that I already mentioned, open source and crypto.
[17:58.310 --> 18:01.870]  And as I said, the more the merrier for doing this examination.
[18:02.310 --> 18:06.490]  And so a question you might ask at this point is, well, you know, but aren't we better off with obscurity?
[18:07.610 --> 18:09.290]  And I'm basically trying to say no.
[18:09.490 --> 18:18.070]  I'm trying to say obscurity in itself is not enough, because the people that you really want to prevent are the people that are going to be able to work their way through that obscurity.
[18:19.130 --> 18:30.810]  Especially insiders, especially your, you know, whatever it is, intruders, criminals, you know, fraud makers, whoever it is that you're really trying to keep out with these security procedures.
[18:32.330 --> 18:35.110]  Now, if we have more people looking, well, what do we hear all the time?
[18:35.130 --> 18:41.910]  You read BUGTRAC, you read Slashdot in the digital world, and all the time there's a new bug, and there's no exploit for that bug yet.
[18:42.210 --> 18:51.070]  And the people with the source code hustle, you know, we had this happen with Apache, the people with the source code hustle, get out a fix, maybe get out another fix if they didn't get it quite right.
[18:51.290 --> 18:51.730]  Okay?
[18:52.070 --> 19:00.330]  And by the time people are exploiting that security hole, people at least in the know and on the ball are able to defend against that security hole.
[19:00.590 --> 19:01.030]  Okay?
[19:01.170 --> 19:16.010]  In the obscure world, we might be faced with nobody being able to identify the vulnerability who is going to have that good will to communicate the vulnerability without the exploit, because the person that works through the obscurity might have ill intent.
[19:16.830 --> 19:16.930]  Okay?
[19:17.330 --> 19:26.410]  And then, of course, at the other end is, in the digital world again, who has a source code, how willing are they to roll out, you know, some kind of a patch or something as opposed to the open source model.
[19:26.550 --> 19:35.270]  So this is where I really think the open source is wonderful for digital security, and might be learned from for the physical world.
[19:40.050 --> 19:44.090]  So more people will see the problems.
[19:44.330 --> 20:03.650]  And my contention always at hacker conferences and the hacker community is that a very large percentage of people with the skills, the interests, and so forth to engage in hacking have no ill intent, have no criminal intent, maybe possibly a healthy disrespect for authority,
[20:04.110 --> 20:07.530]  you know, maybe possibly a healthy skepticism and stuff like that.
[20:07.710 --> 20:23.230]  But the people in this room that find a vulnerability are not, in my opinion and in my experience, very likely to be the people that go and, you know, try to utilize that in, you know, essentially a bad way, try to get themselves some money, do some fraud,
[20:23.410 --> 20:25.110]  do some blackmail, what have you.
[20:25.110 --> 20:27.130]  And yes, there are some, of course.
[20:27.350 --> 20:31.790]  But is the percentage among us any greater than the percentage among the general public?
[20:32.530 --> 20:33.850]  Probably not, right?
[20:33.950 --> 20:48.670]  So if the percentage is much weighed in favor of people that have no ill intent or have no, you know, really interest in their discoveries being used for ill intent, then we're coming out ahead, right?
[20:48.730 --> 20:49.350]  We're coming out ahead.
[20:49.530 --> 20:54.850]  Because as I say, the people with ill intent are going to work hard to work through that obscurity.
[20:54.850 --> 20:59.670]  So open source software, as we know, we're looking at, we're able to look at the source code.
[21:01.190 --> 21:03.950]  Sometimes open source software is based on open standards.
[21:04.210 --> 21:10.490]  So we can actually look at the, you know, the protocols and things like that, that the open source authors were trying to implement.
[21:11.110 --> 21:14.850]  And if we have the source code, we can also do interoperability and testing.
[21:15.010 --> 21:23.610]  And if we want to, and of course this doesn't happen in that many situations, but if we want to, go ahead and set up a more formal test of that software.
[21:23.930 --> 21:28.470]  And we actually see that happening at different levels and different, you know, different types of companies and individuals.
[21:28.850 --> 21:31.030]  And as I say, I think it works pretty well.
[21:32.710 --> 21:48.910]  And I think I mentioned these couple of other points, except let me mention the thing at the bottom in small print there, which is that the number of bugs in software statistically is more or less consistent with the size of the code base.
[21:49.070 --> 21:51.970]  And this is just something that computer scientists have worked through.
[21:52.290 --> 21:55.310]  They've done mathematical models that work pretty well.
[21:55.450 --> 21:58.530]  And then they've done empirical, you know, measurements of the number of bugs.
[21:58.770 --> 22:04.170]  And what we're talking about, rough scale, something like one bug per thousand lines of code.
[22:04.430 --> 22:07.170]  Not all of those bugs are going to be security related, of course.
[22:07.170 --> 22:13.110]  some that are going to be process related, you know, cause some sort of malfunction, cause a core dump, you know, who knows what.
[22:13.310 --> 22:14.610]  So not all security bugs.
[22:14.790 --> 22:24.330]  But if we talk about on the average of something like one bug per thousand lines of code, and that's production, you know, first through the evaluation, you know, written by professional code.
[22:25.590 --> 22:34.590]  Then if we have hundreds of thousands or millions of lines of code, which we do in our complex software systems, we're talking about thousands of bugs.
[22:35.430 --> 22:36.370]  Thousands of bugs.
[22:36.690 --> 22:36.810]  Okay?
[22:37.610 --> 22:42.930]  Those thousands of bugs are going to be there in the Microsoft operating system, where we don't get the source code.
[22:43.090 --> 22:47.630]  They're going to be there in the Linux operating system or kernel, where we do get the source code.
[22:48.050 --> 22:48.450]  Okay?
[22:48.750 --> 22:51.410]  The difference is how many eyeballs are there to look at them.
[22:52.610 --> 22:58.490]  And also, of course, what's your procedure when you find some sort of a bug, some sort of a problem.
[22:58.490 --> 23:00.790]  Now, there are ways to follow up on that a little bit.
[23:00.890 --> 23:02.650]  There are ways to decrease the number of bugs.
[23:02.890 --> 23:13.230]  The way of decreasing bugs is through testing, to set up basically a regression test suite, where you make changes to the code, you run all your tests, you make sure you're passing all the tests.
[23:13.310 --> 23:19.370]  Because what happens, you know, if you write code, you know that when you fix one bug, you create or maybe uncover another one.
[23:19.370 --> 23:19.810]  Right?
[23:20.050 --> 23:25.310]  So it's not good enough to run the test, fix the bugs you found, and then ship the product.
[23:25.590 --> 23:26.390]  That would be a mistake.
[23:26.590 --> 23:27.870]  A mistake that's certainly made.
[23:28.090 --> 23:35.370]  But the better procedure is to run your test, fix the code, run the test, maybe fix the code and run the tests again.
[23:35.570 --> 23:37.390]  And maybe do this more and more times.
[23:37.590 --> 23:45.230]  With very complex systems, you are suddenly unable to test everything you need to test in a reasonable period of time.
[23:45.810 --> 23:57.570]  And it becomes expensive to look at the output of the test, decide what to do, design the fixes, because some of these problems might be serious, especially in the early iterations, and improve things.
[23:57.830 --> 24:08.750]  So what we typically have, in my understanding anyway, from companies like Microsoft and Oracle and SAS and whatnot, big software companies, is they do a few iterations.
[24:09.370 --> 24:13.990]  They'll do three or four or five iterations, maybe, of testing.
[24:13.990 --> 24:18.470]  And what happens with the bugs is there is something like a log curve.
[24:19.350 --> 24:20.490]  So it's asymptotic.
[24:20.610 --> 24:21.630]  You never get rid of all of them.
[24:22.310 --> 24:26.390]  Or you would never claim that you got rid of all of them, except in the simplest of software systems.
[24:27.870 --> 24:33.450]  And as you keep going, you keep getting rid of more and more of the bugs, except there's diminishing returns.
[24:34.310 --> 24:37.010]  The problem is, of course, and so you cut off, right?
[24:37.150 --> 24:39.170]  You say, alright, this is an acceptable cut off.
[24:39.370 --> 24:45.390]  You know, in my model, I've eliminated some 80 or 90 percent of the bugs I had when I started this process.
[24:45.610 --> 24:51.050]  The problem is, in a large software system, that little tail at the end of the curve could still be a lot.
[24:51.050 --> 24:54.330]  And those could be your serious security.
[24:54.610 --> 24:58.070]  You know, your more hard-to-find security problems.
[24:58.710 --> 25:05.190]  So you can do testing to get those errors down, but you can never be all the way assured.
[25:05.490 --> 25:08.350]  And it gets more expensive, so eventually you cut yourself off.
[25:08.530 --> 25:12.510]  Open source, you barely have quite the same problem.
[25:12.510 --> 25:18.550]  You have a little bit of another problem, in that you might not have the same infrastructure for doing all this regression testing and stuff like that.
[25:18.790 --> 25:25.570]  However, you have a much less limited ability to go through the bug fixing process.
[25:25.910 --> 25:31.470]  So we see, you know, software like Apache and the Linux kernel, certainly.
[25:31.850 --> 25:38.030]  You know, there's probably more, you know, releases than almost any other major package with that, with a lot of bug fixes.
[25:38.230 --> 25:41.230]  So we see, you know, a lot of effort going into a lot of re-releases.
[25:41.230 --> 25:44.970]  I think this could work just fine in the physical world in most cases.
[25:45.170 --> 25:47.090]  In fact, it could possibly even work better.
[25:47.450 --> 25:56.910]  Because in a software system, you might have millions or even hundreds of millions of lines of code in the, you know, complex operating system.
[25:57.330 --> 26:00.150]  In a store, you know, what are you talking about?
[26:00.290 --> 26:05.090]  You know, 100 cameras, 10, 20 personnel, different, you know, areas.
[26:05.310 --> 26:09.850]  To me, it's a much more graspable problem that you could actually have a complete solution for.
[26:09.850 --> 26:17.130]  Whereas with software, you can't, in a complex system, have a complete assurance ever, really, that it's bug free.
[26:19.650 --> 26:20.530]  And crypto.
[26:20.690 --> 26:21.810]  We mentioned crypto already.
[26:22.330 --> 26:31.930]  With crypto, you have no security, really, at least as far as the crypto community is concerned.
[26:31.930 --> 26:35.590]  Maybe within companies or whatever, they can make their own decisions, right?
[26:35.850 --> 26:45.830]  But as far as the crypto experts are concerned, you don't have crypto, certainly don't have good crypto, until your process, preferably your algorithms and your code.
[26:45.830 --> 26:54.110]  And the outcome of your analysis or some experts analysis of that algorithm has been examined closely by experts for a while.
[26:56.130 --> 27:08.830]  If you go and read any of the crypto books, pick up Applied Cryptography by Schneier, or, you know, you can look through some of the discussions and publications on crypto.
[27:08.830 --> 27:18.810]  So, people still wonder if crypto systems in use for 30 years are good enough and maybe have, you know, undiscovered problems.
[27:18.810 --> 27:25.490]  And every once in a while, they discover one, like the one with, we heard about a problem with PGP a little while ago.
[27:25.610 --> 27:39.950]  And PGP, I mentioned this to my panel yesterday, PGP, Pretty Good Privacy, which is our system for, you know, authenticating and encrypting and non-repudiating email and files and so forth, is not just pretty good, it's really, really good, because it's been extensively revised.
[27:40.050 --> 27:44.230]  It started out pretty bad, or maybe pretty good, he called it pretty good, right?
[27:44.230 --> 27:49.770]  But from what I understand, Zimmerman's first implementation of PGP had some very serious flaws.
[27:50.090 --> 27:59.950]  But it's gone through, you know, something like 20 years of revision and scrutiny, and yet, this year, there was a serious problem that was uncovered in that.
[28:07.200 --> 28:08.980]  The whole thing, exactly.
[28:09.320 --> 28:12.140]  The whole thing, yeah, and let me...
[28:12.140 --> 28:15.280]  I'm sorry, I'm sorry if I interject.
[28:15.280 --> 28:17.300]  Could you use the mic up there, please?
[28:17.700 --> 28:18.800]  Yeah, I'll repeat the question.
[28:19.280 --> 28:27.120]  Yeah, the point is basically that you have to look at the whole system, because the algorithm might be sound, the implementation of the algorithm might be sound, and there might be something else going on.
[28:27.280 --> 28:38.080]  In the panel yesterday, we talked about the fact that if you're running on a Windows system, you have anything that's invulnerable, I'm sorry, anything that's vulnerable in a Windows system to cope with in addition to your own software.
[28:38.500 --> 28:38.860]  Yeah.
[28:39.140 --> 28:40.780]  Oh, sure, yeah, well, go ahead.
[28:47.360 --> 28:51.040]  I was talking not only about the operating system, but the crypto system.
[28:51.320 --> 29:06.840]  So, years ago, there was the Clipper chip in particular, and there was a sham in that they had some reviewers look at the algorithm, and even that was a sham, since they weren't given enough time, but there was no review of the crypto system.
[29:07.380 --> 29:07.460]  Right.
[29:07.820 --> 29:08.260]  Absolutely.
[29:08.500 --> 29:10.600]  Yeah, the review is critical.
[29:11.040 --> 29:25.960]  And enough time to do the review, and ongoing review, because what you have in crypto, and I think this happens really across the board, is you might have an algorithm that's independently implemented by different people.
[29:26.100 --> 29:30.380]  So you can have a lot of faith in your algorithm, and yet not know that a particular implementation is good.
[29:31.420 --> 29:43.900]  Yeah, so anyway, I personally think that the procedures we have for crypto are very good, and that PGP is an example of software that's just gotten better and better and better.
[29:44.080 --> 29:48.780]  Now, not necessarily easy to use, and all these other challenges that we can talk about with it.
[29:49.000 --> 29:57.720]  But as far as, can you think of good examples of things that PGP is supposed to do that we think it's not able to do?
[29:57.720 --> 30:01.640]  You know, are we able to, you know, bypass the signature and stuff like that?
[30:01.880 --> 30:03.840]  It stands up to that type of test.
[30:04.340 --> 30:08.380]  I wanted to, with your comment, I wanted to mention a book that I mentioned yesterday.
[30:09.000 --> 30:12.780]  If you're interested, read Applied Cryptography by Bruce Schneier.
[30:13.020 --> 30:18.580]  But regardless of any of your interests, you must read Secrets and Lies by Bruce Schneier.
[30:18.720 --> 30:20.000]  It's an outstanding book.
[30:20.580 --> 30:37.080]  What Schneier starts out with in that book, the preface, he says that his thought, when he wrote Applied Cryptography, which is the closest thing, really, we have to a Bible of crypto, or one of the closest, one of the few books.
[30:37.140 --> 30:38.200]  Anyway, certainly, that's up there.
[30:39.720 --> 30:45.660]  What he said was that he thought crypto was the answer, and it turned out crypto is only part of the answer.
[30:45.780 --> 30:51.260]  And you have to look at the whole larger system of what it is you're trying to do with security.
[30:51.260 --> 30:54.340]  And that's what the book is about, is the whole larger scheme.
[30:54.340 --> 30:58.520]  And either my next slide or the one after that actually presents something like that.
[31:00.680 --> 31:03.460]  Applied Cryptography is sort of the classic by Bruce Schneier.
[31:03.860 --> 31:06.320]  And Secrets and Lies is his newer book.
[31:06.380 --> 31:10.720]  I think it's a 2002-year release.
[31:11.140 --> 31:15.500]  I just wanted to say, for people who want to understand cryptography, Applied Crypto is fine.
[31:15.660 --> 31:20.480]  If you actually want to implement things, though, Douglas Stinson's Cryptography Theory and Practice.
[31:20.480 --> 31:22.680]  Right, Stinson's Cryptography Theory and Practice.
[31:23.020 --> 31:27.460]  Yeah, so I sort of, you notice I corrected myself when I said it's a Bible, because it's not really the Bible of cryptographers.
[31:27.940 --> 31:31.980]  It's more like the Bible of people that want to, as you say, learn about in detail.
[31:32.240 --> 31:32.720]  Yeah, thanks.
[31:32.780 --> 31:33.640]  That's absolutely true.
[31:35.340 --> 31:40.420]  Okay, so examples of public scrutiny, political security, I did not come up with a lot.
[31:40.420 --> 31:49.200]  I remember when the new, you know, $20, now $5 and $10 and whatever dollar bills are coming out, we saw some newspaper articles saying what all the security procedures were.
[31:49.440 --> 31:51.760]  I didn't see that until it was done, though.
[31:53.700 --> 31:55.440]  I'm not thinking of a whole lot of examples.
[31:55.820 --> 31:57.840]  And I want to, we need to try to press on.
[31:57.960 --> 32:01.020]  But if you have examples, let me know and I'll try to add them in later on.
[32:01.020 --> 32:09.140]  We have tonight Robert Steele, some of you saw him last night on the panel with Declan and Mike Levine.
[32:10.400 --> 32:15.260]  He's going tonight, I think 9 o'clock in that room, probably for several hours.
[32:15.480 --> 32:17.980]  Robert Steele is an ex-Fed.
[32:18.240 --> 32:23.180]  He's got all this inside information, and he is fighting his life's mission.
[32:23.400 --> 32:26.920]  He has an institute, he has books, he's talking here, he's talking everywhere.
[32:26.920 --> 32:47.880]  His life's mission is to say to the government especially, but to other agencies and businesses as well, that secret is ineffective and too costly and too difficult and inappropriately utilized in the vast majority of cases.
[32:47.900 --> 32:49.480]  He's not saying there should be no secrecy.
[32:49.600 --> 32:51.740]  He's saying there's way, way too much secrecy.
[32:51.860 --> 32:52.960]  It's costing us too much.
[32:52.960 --> 32:54.100]  It's not being effective.
[32:54.100 --> 32:56.460]  It's creating problems and so forth.
[32:56.460 --> 33:00.200]  That's his whole argument for that.
[33:00.380 --> 33:14.000]  So he's a big proponent of decreasing obscurity in the physical world of spies and documents and procedures of agencies and things like that.
[33:14.760 --> 33:16.540]  Okay, so this is a simple idea, right?
[33:16.740 --> 33:23.260]  We want to move towards an open review or something like an open source type of model of security procedures in the physical world.
[33:23.260 --> 33:32.900]  And as I said, if we're only having the official qualified people do it, which for some reason might be appropriate, then we're losing out on potential brain power.
[33:35.040 --> 33:38.680]  And as I've been saying, secrecy might be a component.
[33:39.160 --> 33:41.600]  And as I've been saying, an iterative design.
[33:41.720 --> 33:49.300]  So basically the slide here is the stuff I've been talking about mostly in the digital realm can only be this in the physical realm.
[33:49.540 --> 33:51.100]  And this is the Schneier slide.
[33:51.300 --> 33:57.060]  Okay, this is not exact or anything, but this is more or less the type of procedure he goes through in Secrets and Lies.
[33:57.060 --> 33:59.780]  He says, you know, it's a system.
[33:59.980 --> 34:01.240]  It's a security system.
[34:01.280 --> 34:03.460]  It's a system that exists in time and space.
[34:03.460 --> 34:06.340]  It's a system that interacts with some outside environment.
[34:06.600 --> 34:12.340]  It's a system that typically will involve people, communication, things like that.
[34:12.460 --> 34:14.060]  Not just, you know, hardware and software.
[34:14.740 --> 34:17.700]  And so I think this works really well for the physical world.
[34:17.820 --> 34:19.100]  A vulnerability matrix.
[34:19.100 --> 34:19.840]  A list.
[34:20.020 --> 34:21.200]  What could go wrong?
[34:21.200 --> 34:22.740]  What are the things we're worried about?
[34:22.880 --> 34:23.880]  What are we trying to protect?
[34:24.740 --> 34:26.420]  What is the procedure that we have?
[34:27.140 --> 34:30.920]  As I said, I think that, again, I've been trying not to pick on airports.
[34:31.080 --> 34:34.900]  But I think at airports, they don't know what the procedure is a lot of the time.
[34:35.080 --> 34:35.960]  Or it changes.
[34:36.160 --> 34:37.420]  And certainly you can't find out.
[34:37.840 --> 34:41.600]  And I mean, just last week I called, I tried to speak to the airline to say, can I do this?
[34:42.000 --> 34:43.320]  Can I bring this on the plane?
[34:45.460 --> 34:46.860]  There was no answer forthcoming.
[34:47.700 --> 34:48.800]  It wasn't a yes or a no.
[34:48.800 --> 34:51.260]  It was just, you know, here's what you're allowed to do.
[34:51.260 --> 34:56.420]  And the interpretation of what's allowed is up to the person at the counter.
[34:56.600 --> 34:58.340]  Or the person at the counter after that.
[34:58.420 --> 34:59.460]  Or the person on the plane.
[34:59.620 --> 35:01.240]  Or someone x-raying your bags.
[35:01.340 --> 35:02.740]  And we don't know what their judgment is going to be.
[35:03.860 --> 35:05.920]  The cost benefit analysis is important.
[35:05.980 --> 35:09.440]  Because there are costs with any sort of procedure you might want to do.
[35:09.580 --> 35:12.460]  In fact, there are costs involved with setting up the whole security process.
[35:12.780 --> 35:15.020]  And at some point you might want to say, enough, enough.
[35:15.200 --> 35:16.560]  You know, this looks pretty good.
[35:16.680 --> 35:17.440]  Pretty good is enough.
[35:19.600 --> 35:31.120]  What Schneier talks about a whole lot, and I think people know about who are systems administrators, that are out getting the hackers tools on their computer systems, is think like the person trying to break into your system.
[35:31.480 --> 35:32.820]  Try to use some of the same tools.
[35:33.080 --> 35:35.680]  And we actually see that sometimes in the airports.
[35:35.980 --> 35:41.560]  With them, you know, sending the undercover folks through to see if they can bypass the procedures.
[35:41.560 --> 35:50.060]  And this would be great if they were getting better at not being able to bypass them, instead of still having problems.
[35:50.280 --> 35:51.520]  Simulation thought experiments.
[35:51.520 --> 35:52.460]  Get the thing out there.
[35:52.620 --> 35:54.060]  And test and repeat.
[35:54.060 --> 35:58.820]  So just like I said, reducing the number of bugs in source code.
[35:59.980 --> 36:01.960]  So in a store, what are the risks?
[36:02.020 --> 36:02.600]  Who are the players?
[36:02.700 --> 36:03.440]  We've got some stuff.
[36:03.680 --> 36:04.440]  We've got customers.
[36:04.680 --> 36:05.740]  We've got delivery people.
[36:05.880 --> 36:09.160]  We have maybe security people, general employees.
[36:09.160 --> 36:10.060]  We have management.
[36:11.020 --> 36:13.760]  You know, we have contractors that might come in from time to time.
[36:15.340 --> 36:16.440]  What's the procedure now?
[36:16.620 --> 36:24.600]  We've got cameras, we've got a buzzer on the door, we've got locks, we've got a guard, we've got some telephones here and there, we've got a little bit of a chain of command going.
[36:25.140 --> 36:26.340]  You know, we have training.
[36:26.540 --> 36:27.140]  Things like that.
[36:28.640 --> 36:29.580]  What are the problems?
[36:30.180 --> 36:31.100]  What's being stolen?
[36:31.260 --> 36:31.880]  What are the losses?
[36:32.120 --> 36:32.840]  What is that...
[36:33.860 --> 36:35.540]  What is it that we're worried about?
[36:36.060 --> 36:38.960]  You know, there's money disappearing from the cash register.
[36:39.400 --> 36:41.200]  Expensive items are walking out the door.
[36:41.820 --> 36:43.820]  Our inventory doesn't seem to match.
[36:43.920 --> 36:45.240]  We don't really know what's going on.
[36:47.020 --> 36:50.000]  And of all those things that are going on, what can we do?
[36:50.100 --> 36:52.960]  Let's dream up some new stuff that might address some of those problems.
[36:53.460 --> 37:00.480]  Let's assess how well our intended solutions might address the existing problem.
[37:00.480 --> 37:03.220]  That's a sort of reality check, making that loop.
[37:05.040 --> 37:06.420]  And go ahead.
[37:06.560 --> 37:07.080]  Implement it.
[37:07.380 --> 37:08.700]  You know, come up with the details.
[37:09.640 --> 37:14.180]  Deploy in some reasonable time scale, maybe not all at once.
[37:14.660 --> 37:16.800]  And as I say, repeat.
[37:17.880 --> 37:18.380]  Evaluate.
[37:18.560 --> 37:22.880]  If you're not evaluating your security system, you don't know what you have.
[37:23.360 --> 37:24.120]  It might be good.
[37:24.520 --> 37:25.540]  It might not be good.
[37:25.700 --> 37:27.460]  And my whole point here is...
[37:27.460 --> 37:36.100]  And again, I don't know that maybe a store is really in need of putting up their whole procedure on a big poster for people to scrutinize as they walk in.
[37:36.400 --> 37:36.840]  Right?
[37:38.200 --> 37:38.640]  But...
[37:40.460 --> 37:43.140]  I think parts of it might work very well.
[37:43.620 --> 37:49.740]  If part of it is just to put up, you know, let's imagine, put up a sign that says, there are a bunch of cameras in the store.
[37:49.880 --> 37:50.880]  They're here, they're there, they're everywhere.
[37:51.220 --> 37:53.420]  You know, we've got undercover people.
[37:53.680 --> 37:54.720]  We have our tags on our stuff.
[37:54.860 --> 37:56.360]  And some stores actually do that, of course.
[37:57.920 --> 37:58.980]  I think that might help.
[37:59.100 --> 38:11.780]  But then if they can go to the next step and get their procedure out there for scrutiny on their website, at a conference, in a trade show, you know, what have you, with consultants, it's going to be all the more powerful.
[38:11.780 --> 38:13.240]  Let's talk about another one.
[38:14.820 --> 38:17.640]  The deal here with H2K2.
[38:17.860 --> 38:20.820]  And as I said, I was involved with the planning of the conference.
[38:21.220 --> 38:28.040]  And one thing I noticed fairly early on was that, as one of the planners of the conference, I had no idea what these were going to look like.
[38:28.740 --> 38:33.540]  And I had no idea what color the staff shirts or the security shirts were going to be.
[38:33.540 --> 38:36.640]  And I realized fairly early on, it was good.
[38:37.060 --> 38:37.480]  Right?
[38:37.580 --> 38:40.140]  Because if I don't know, you probably don't know.
[38:40.360 --> 38:43.280]  And one of the things we're worried about, these cards are actually pretty good.
[38:43.400 --> 38:49.360]  But of course we're worried about people making something that looks like this, and they just made themselves a $50 bill.
[38:50.420 --> 38:50.840]  Right?
[38:50.980 --> 38:52.380]  This is what gets you into the conference.
[38:52.380 --> 39:02.120]  So in that procedure, there's, in the whole sort of system there, there was a good secrecy component that was effective.
[39:02.400 --> 39:05.360]  The main reason it was effective is timeliness.
[39:05.700 --> 39:20.460]  What we were basically saying there is, by keeping secret till, you know, Thursday night, Friday, what the particular colors and stuff is that people might want to be able to forge to save themselves $50 bucks, and might possibly sell or give to all their friends,
[39:20.640 --> 39:23.440]  and, you know, really possibly create a revenue problem.
[39:23.640 --> 39:32.240]  Well, if we can just keep that secret till the conference, then, you know, everyone that pays on Friday, they're not going to have any incentive to do this.
[39:32.460 --> 39:37.300]  And then there's only one or two days for any sort of badness that we might imagine to happen.
[39:37.480 --> 39:39.280]  So that's where secrecy worked.
[39:39.560 --> 39:41.680]  Or, you know, I'm sort of saying I hope it worked.
[39:41.900 --> 39:42.020]  Right?
[39:42.320 --> 39:46.680]  But we think secrecy worked on a time-limited basis as part of our security model.
[39:46.680 --> 39:53.000]  And the rest of it, as you see, wear your badges, get checked, we have different colors, we have t-shirts, and all that type of thing, videos, and whatnot.
[39:54.860 --> 39:57.760]  Now, we didn't undergo a lot of public scrutiny for this.
[39:58.260 --> 40:00.500]  I think it probably would have been perfectly appropriate.
[40:00.780 --> 40:10.080]  In fact, if we got this out on the public mailing list for more scrutiny, which we didn't do as far as I know, we might have identified better ways of doing this.
[40:11.640 --> 40:14.360]  I think we probably would have had some pretty good ideas.
[40:15.240 --> 40:23.500]  As it was, there was at least the scrutiny of the group of like 20 or 30 people that were trying to come up with these procedures.
[40:25.300 --> 40:27.500]  Okay, so we know physical security is challenging.
[40:27.680 --> 40:39.500]  We know that having things like security guards and cameras and other physical stuff might be more costly and more costly to scale than some of the digital systems that we have.
[40:39.500 --> 40:47.760]  And yet, of course, we also know that it's important and something that people are willing to spend time and effort and money to do.
[40:49.260 --> 40:56.740]  And I've argued throughout here that I think that some open review of security processes in different places would help.
[40:56.740 --> 40:57.780]  We have the web.
[40:58.560 --> 41:06.640]  We don't have to have posters and walk-throughs of establishments to get some feedback that might help.
[41:06.640 --> 41:24.900]  We can just, you know, put it up on our web page for a store, for, you know, a, whatever, a military base, for the other examples I mentioned before, any of these physical scenarios where you want to put people out, keep stuff in, make sure people are who they say they are,
[41:24.960 --> 41:25.600]  that type of thing.
[41:30.540 --> 41:34.500]  To reiterate, the insiders are often the biggest risk.
[41:34.720 --> 41:37.800]  Even in digital security, the insiders are often the biggest risk.
[41:38.380 --> 41:49.160]  In the physical world, what we're hearing in the news about all these, you know, white-collar criminals that were stealing millions and billions from stockholders and companies and things like that.
[41:49.340 --> 41:50.240]  How did they do that?
[41:50.260 --> 41:50.960]  They were inside.
[41:51.400 --> 41:54.060]  They were not subject to good scrutiny.
[41:54.060 --> 42:03.960]  And actually, we might even see, coming out of all the Enron and follow-on, we might even see something like some public scrutiny models for some of this accounting stuff, which I think would be great.
[42:04.240 --> 42:10.400]  And that's sort of a little bit of a bridge between the physical world and the digital world, because, of course, all the accounting stuff is electronic.
[42:10.660 --> 42:12.100]  And yet, what are you accounting for?
[42:12.340 --> 42:15.220]  You know, goods and services and personnel and things like that.
[42:18.620 --> 42:19.920]  So, that's a suggestion.
[42:20.140 --> 42:20.980]  Let's try to do this.
[42:21.920 --> 42:37.380]  Let's see or let's suggest, when we can, maybe we can come up with a procedure where we can push for adapting some of what we have in the digital world that's really, I think, worked very well for us to the physical world.
[42:37.380 --> 42:43.400]  And we have, I think, a lot of need and a lot of desire for better security in our physical realm.
[42:43.540 --> 42:48.200]  Certainly, that's been a very big theme in our last six or eight months.
[42:50.840 --> 42:55.800]  And I think the geeks and the programmers have some clues about this that we can apply.
[42:56.780 --> 43:01.340]  So anyway, that's my email and my personal web page.
[43:01.720 --> 43:05.620]  And you can maybe suggest by email how this may or may not work.
[43:05.740 --> 43:09.800]  Tell me if I should push for it or if I'm just not identifying major problems.
[43:10.000 --> 43:12.900]  We have probably about five minutes for questions.
[43:12.920 --> 43:17.360]  And what we like to ask is for people to come forward to the microphone, if you have one.
[43:17.360 --> 43:19.220]  And if you keep it short, we'll get more.
[43:19.600 --> 43:21.580]  And if there are no questions, we can wrap up early.
[43:25.000 --> 43:25.960]  Yeah, I'm sorry.
[43:26.080 --> 43:27.820]  I'm trying to look at your talk at the same time.
[43:27.980 --> 43:28.580]  It's not going to be easy.
[43:28.980 --> 43:29.180]  Okay.
[43:30.860 --> 43:35.300]  I think we're maybe having a little trouble with terminology, secrecy and obscurity.
[43:36.080 --> 43:41.300]  And I'd like to see somebody propose a way of looking at it.
[43:41.380 --> 43:45.980]  I don't know of any kind of good security system that doesn't involve some kind of shared secret.
[43:45.980 --> 43:48.500]  I mean, you've got to have something...
[43:48.500 --> 43:48.880]  That's usually what you're...
[43:48.880 --> 43:49.600]  There's got to be something...
[43:49.600 --> 43:50.460]  Usually that's your object.
[43:50.600 --> 43:51.780]  ...that you're not going to know.
[43:51.900 --> 43:55.000]  That nobody else is going to know except for the parties to the transaction.
[43:55.080 --> 43:56.200]  Even they don't need to know it.
[43:57.040 --> 44:05.920]  But then obscurity is perhaps a different concept where the fact that your secret sucks is being obscured.
[44:05.920 --> 44:12.200]  And I did a story recently about something David Litchfield came up with with Microsoft SQL Server.
[44:13.240 --> 44:17.620]  Just a simple password, pass file cracker like JTR.
[44:18.420 --> 44:25.940]  And what he discovered was that the salts were easy to predict and that that wasn't known.
[44:25.940 --> 44:29.720]  So what you had was a bad secret.
[44:30.460 --> 44:34.120]  The salts were not large enough and they certainly weren't random.
[44:34.980 --> 44:41.480]  You had a very weak concealment of this fact.
[44:41.940 --> 44:48.740]  So that obscurity, it seems to me, would be the effort to prevent somebody from finding out how bad something is.
[44:48.740 --> 44:50.640]  But the secret itself has got to be there.
[44:51.060 --> 44:51.100]  Absolutely.
[44:51.560 --> 44:52.380]  That's the whole point.
[44:52.800 --> 44:53.040]  Right?
[44:53.300 --> 44:57.540]  But people are always using obscurity and secrecy interchangeably.
[44:57.720 --> 45:01.920]  And this makes it very difficult to speak about these things because it's hard to follow.
[45:02.100 --> 45:02.320]  Right.
[45:02.680 --> 45:05.620]  Yeah, I mean, I think I've tried to be consistent, but we're on...
[45:05.620 --> 45:06.960]  I'm not blaming you for this.
[45:07.560 --> 45:11.100]  We're on the same wavelength here, so no argument at all.
[45:11.360 --> 45:13.500]  I mean, you want to keep your secret, right?
[45:14.820 --> 45:27.180]  And I think one of the distinctions that's fairly easy to make is whether we're making our data, or if you want to say even obscuring our data, our information, or our procedure.
[45:27.420 --> 45:29.420]  And I'm really talking about procedure here.
[45:29.840 --> 45:42.620]  And there are only, I think, this is Steele's argument, there are some cases where there needs to be an element of secrecy to your procedure, like in a, you know, let's say a military base.
[45:42.740 --> 45:45.540]  You know what the schedule is for people walking the perimeter, stuff like that.
[45:45.740 --> 45:47.680]  Maybe you don't want that to be widely known.
[45:47.860 --> 45:53.720]  But your process is what I'm arguing should be open.
[45:54.040 --> 45:59.420]  You know, the fact that there are guards, the fact that there are gates and cameras and things like that.
[45:59.420 --> 46:09.060]  If your system doesn't survive people knowing, you know, where the cameras are, your system is lousy, right?
[46:09.060 --> 46:10.180]  You're not protecting your secret.
[46:10.440 --> 46:10.780]  I totally agree.
[46:11.480 --> 46:21.820]  The situation with that little example was simply that Microsoft wasn't letting us know that they were generating easy, it's also very easy to predict.
[46:22.100 --> 46:27.420]  If they weren't, if they were truly random, there would be no harm in telling us how they generate.
[46:28.020 --> 46:29.540]  So that would mean obscurity.
[46:30.520 --> 46:32.000]  Preventing us from knowing how it's generated.
[46:32.260 --> 46:32.960]  And I think that happens a lot.
[46:33.000 --> 46:35.560]  The secret itself is, it has to be a secret.
[46:35.700 --> 46:36.700]  It has to be something you can't predict.
[46:37.580 --> 46:37.840]  Thanks.
[46:37.980 --> 46:38.180]  Anyway.
[46:38.360 --> 46:38.740]  That's a good comment.
[46:38.940 --> 46:39.400]  Yeah, I agree.
[46:40.100 --> 46:40.540]  Absolutely.
[46:41.000 --> 46:42.560]  We'll probably just have one more question.
[46:42.720 --> 46:47.080]  I guess just because I'm doing the filming doesn't mean I cannot make a good comment.
[46:47.920 --> 46:48.080]  No, please.
[46:48.080 --> 47:12.440]  Basically, Greg, you started saying initially, started talking about basically releasing the information about things, making source code available for the software, but I think one of the things you're not keeping in mind, and that's probably what precludes a lot of quote unquote traditional from doing so,
[47:12.900 --> 47:18.840]  is the fact that...
[47:20.530 --> 47:21.530]  Not me.
[47:21.670 --> 47:22.850]  It doesn't look me, I guess.
[47:22.990 --> 47:23.990]  I think someone walking on cable.
[47:24.570 --> 47:30.070]  Basically, the problem is that it interferes with their business model.
[47:30.490 --> 47:46.830]  You know, if I'm Microsoft, I make the source code available, then next time the customer wants to run my software on, say, Macintosh, he can conceivably invest the time and make it so instead of generating more revenue for me as a company.
[47:46.830 --> 47:54.650]  So that's potentially why a lot of people are reluctant and releasing more information of any kind at all.
[47:55.130 --> 47:56.190]  Well, it's a mindset.
[47:56.570 --> 47:57.250]  And I think that...
[47:57.250 --> 47:58.090]  It is a mindset.
[47:58.190 --> 48:00.190]  I think that there's something to be said for changing the mindset.
[48:00.570 --> 48:15.930]  The only way to deal with it is to potentially come up with a revenue model that would still provide the rewards for the companies or may change their mindset so they would not expect any more rewards once the initial software is sold.
[48:17.070 --> 48:21.890]  And I know the support model have been tried many times, but it doesn't seem to be going anywhere.
[48:22.150 --> 48:24.490]  I mean, Red Cat is still not profitable as far as I know.
[48:25.290 --> 48:25.730]  So...
[48:25.730 --> 48:26.690]  I think in the physical...
[48:26.690 --> 48:45.610]  I mean, I'm absolutely agreeing with you, but I think in the physical world, it's not quite as much as a decision like that because you are going to be buying software in most cases, but you're usually going to be making your own security or at least contracting out or something like that.
[48:45.750 --> 48:46.990]  So I think there's actually...
[48:46.990 --> 48:50.050]  There is some investment already happening locally and some control.
[48:50.430 --> 48:52.650]  And you don't need to necessarily make a trade-off.
[48:52.810 --> 48:57.290]  I mean, you do if you decide, we're going to hire Pinkerton or we're going to hire our own guys or something like that for security.
[48:57.290 --> 49:03.310]  But you don't necessarily have to say, well, I'm either closed source or open source and I'm on one path or the other path.
[49:03.990 --> 49:04.130]  So...
[49:04.130 --> 49:04.790]  Yeah, I agree.
[49:04.870 --> 49:05.490]  That's a good point.
[49:05.670 --> 49:07.010]  Well, we're going to go ahead and wrap it up.
[49:07.130 --> 49:07.790]  Thank you very much.
[49:08.110 --> 49:13.250]  We have a session starting up at 11 o'clock in both rooms.
[49:13.430 --> 49:17.550]  If you didn't yet get one, there is an update sheet.
[49:17.670 --> 49:22.770]  There are a bunch of them on the table coming up the hallway here and up the table in the foyer there.
[49:23.030 --> 49:26.450]  There are some changes to the schedule for the day that you want to know about.
[49:26.450 --> 49:29.550]  And movies are starting up at around 11.30 today.
[49:30.050 --> 49:32.530]  So enjoy the rest of the day and the rest of the conference.
[49:32.730 --> 49:32.910]  Thanks.
[49:33.110 --> 49:35.150]  Do email me if you have further thoughts on this.
[49:35.210 --> 49:36.350]  And thanks for your attention this morning.
[49:36.570 --> 49:36.630]  Thank you.