Next to me is Mark Kennedy. He's one of our architects in the semantic research lab. We're going to talk to you today about a little bit of proactive security against the malicious code that's being written out on the net every so often distributed in various forms. Mark's going to help out here this morning and actually stick around until the end because he's got some really neat stuff on the other machine and we're going to show you later on. Alright, so I've been starting my presentations for the last year and a half or so with a great quote. At least what I think is a great quote. I'm going to see if anybody has the answer to this. Security is to the internet as somebody. Wake up people. Didn't hear it. Intelligence is to the military. That works. Anybody else? Sounds like a ringer. Bicycle is to fish. I'll give you a hint. Alright, a little hint. Actually, Bill did have the answer. He was an insider. He saw the presentation at Black Hat. Safety is to commercial aviation. This quote actually came from Bartsdale about a year and a half ago. He was relating the state of the internet security to the situation with air safety back in 1937. If we kept safety to 37 levels and had traffic increased to 1999 levels, we'd be dropping two 747s every day. I don't think many of us would be flying. That's the state of the internet security today and that's what we've got challenges to solve. So we're going to talk today about mobile code. And the mobile code is really a concept I think everybody's at least at this point aware of because it really exists in just about any website you go to. People are transferring it through other means as well through email, through FTPs, through downloads and so forth. So most sites are enabled. What we're talking about is traditionally Java and ActiveX, obviously expanding out to scripting languages, JavaScript, VB scripts, but anything could be mobile code. Excel spreadsheets are containers of data. The data itself could be code, could be malicious. And we actually have seen cases in the past where Excel spreadsheets have been used to carry some malicious code and bootstrap it onto your systems. Greeting cards that you may get may in fact be trojanized and we'll show you some of those a little bit later. But generally the concept here is something that's moved between two points, usually with some malicious intent and usually without a lot of activity or action on the part of the user to get it going. This was a little historical. Some of you may be a little more advanced in that, but that's okay. There's always new people and they have to get up to speed. About a month and a half ago we had the love letter. And right after the love letter, there's a guy by the name of Zivronovsky over in Russia. Now maybe some of you are politically astute and know this guy's a little bit on the fringe. Nevertheless, he had a couple of really interesting comments that he made publicly, as he always does. And one of them was, hey, we're going to knock you all down with this type of code. We can launch these things. We can have our scientists create really interesting attacks and send them out to you. And he was really piggybacking off of all the press and the hype that we got off of love letter. Now you put this one aside and you say, well, if this radical individual is saying this, what about all the people that are not looking for the publicity? What about the non-politicians who are actually doing it? And then you start to get a little worried. So you look at the risk criteria here and you look at a number of categories of tools that you're using in the internet space, receiving mail, opening attachments, surfing the web, using the instant messengers. These are all mechanisms by which you move code from outside of your system onto your system. It's not just the floppy drive we used to use back in 1990 or the CD-ROM. So if we look at this, and this I have to give credit, I have a whole team of people here in the front row that I used to work with when I was back at Finjon. And one of the guys who developed some of our best script attacks over there was a guy by the name of Paul, a marketing guy. A marketing guy turned script kitty. He's working his way up. He's here at DEF CON this year learning and trying to move himself up to the next level. But in any case, what he really was able to demonstrate was something that I think everybody should be aware of. How easy it is to go out of the network that you're know and love, go over to say an internet café, have some anonymity, do a couple searches very quickly on some tools, joiner, binder, all these tools that allow you to put two bad things together with a good thing, and basically create your own Trojan. Right? Nasty stuff. Well, some of the software out there, joiner in particular, is so easy to use, it's got a graphical user interface. I mean, it doesn't get any easier than that, right? Bad program, good program, combine them together. Now you've got a good program on top, bad program on the bottom. Send it off to somebody, right? Send the greeting card to your boss. I'm not advocating that. But send the greeting card to your boss, you know, and suddenly he opens up that greeting card, happy birthday, and underneath you've got a little back office install going. Now you can listen to what's going on on his machine, see what he's doing, see what he's typing about your review. Again, not advocating this. You know, don't try this at home. But if you were to try it at home, the tools are available, right? Paul, my little script kitty over there, you know, did a great job. So let's do an example that I think will make a lot of sense, will help bring it home. We're going to interrupt the PowerPoint, we're going to scoot down into lotus, right? The press has always talked about... What is that other program that they use? Outlook. Outlook, right, that was it. So the press always talks about outlook being susceptible, but I mailed myself something in lotus. Two little things here, games and a pinwheel. We're going to launch the pinwheel and see how it works here. So this thing is going to take off. This is exactly how I would launch it if I got anything and this thing goes around. Oh, that's cute, you know, go look at it. And says, I think, hit escape to exit.  And if you actually hit the... There's a couple things, you probably can't read what it says, but we actually created a little directory there. And to see what's going on there, we moved a couple files. Let's see, there's board minutes from April 2000. There's some letters to some girlfriend. Memory scan documents. All kinds of other things that we moved into this directory. Certainly, we could have moved them out the open internet connection should I have been at the moment of time when I was connected, or when I launched this, connected to the net. If we look at some of the other things we did, if this was a Sony VAO or some other machine with an actual camera attached, I could have activated the camera. I could have recorded what was going on in the room. In this particular case, there isn't a camera on this machine, but there is a microphone. And if we listen...  Go look at it. The microphone was enabled, engaged, and we recorded some information here.  I'm going to disable the microphones. I can get into my Windows environment and disable the microphone. And I say, wait a minute, I just installed some... I just ran an executable on your system. You think I can't re-enabled what you disabled?  And I say, well, you know, I'm installing software on your machine. I can reinstall those DLLs. And some of you are smart and you say, well, I can cut the wire to the microphone. And I say, well, I can't re-establish that. And then, of course, there was a guy who came up to me the other day from this little group called Incutel. Anybody ever heard of those guys? You know, they're the venture capital arm of the CIA. That makes sense. And they said, look at this little nifty device. And he actually can plug it into the side of the input mic here. It actually disables it temporarily. And it really does act as a sever device. It's a piece of hardware. Unfortunately, he kind of laughed about that. He said every so often bumps up against it and breaks it. So he's got a whole supply of these things. But there are things you can do. Obviously, if you've got a camera, you can tape it up and so forth. But these are really serious things. Think about the idea that about a year ago, I think it was, the State Department was bugged, right? Somebody was physically planting a listening device in one of the conference rooms of the State Department. And you think about that and you say, does that make any sense? I mean, what information is actually useful at the State Department? I'd much rather bug the CEO's office at Semantic and find out that accent is in play and do some stock trades in advance of that announcement. That's obviously much more valuable information. So if I could install telephony information, internet telephony, turn on the microphone and just siphon information out of that environment, that's pretty good. That's pretty exciting. Obviously, there's standard information you can get about the environment in which you're executing and we showed that as well. Let's go back to the program that we've already got going here and we'll go on and talk about some other things like how you deal with this. So if you look at this concept, this personal surveillance protection idea, you wonder whether it's true. Can you actually block these things? Now, again, I just discovered that there's a piece of hardware that you can temporarily plug into the side of your machine to block the microphone. That's novel. Can you do it in software? Can you do it without adding hardware to your machine? Can you prevent things from being bugged? This is a controversial slide. Some would argue that back orifice is a good thing. Some would argue that it's a bad. I'm not here to create the controversy. What I'm simply saying is some people may want to know when back orifice is installed on their machine and some may not. Those who do obviously want to know if there's a way to prevent back orifice from getting on there. It was interesting. The government guys, they actually run these experiments all the time. They've been listening to each other for years. They're talking about this now. So this stuff is real. This personal surveillance is happening. It's possible. Here's the classic one. Where's the antivirus? What's it doing? Antivirus is a pattern matching approach. It's a reactive process. We first have to know that something is bad. We first have to know that you've trojanized a greeting card. Understand the pattern in that greeting card. Then put that pattern into the pattern database which then has to be shipped into your desktop. Code scanning is looking for fragments of code that we know. This is how antivirus works. This has worked for ten years or more. The idea is that you can only anticipate so far. You can only anticipate what the next attack stream may be. You don't necessarily have full capability to stop every new and novel attack. That's primarily because there's no dynamic inspection capability inside of the AV product. If you did start to tweak up heuristics or statistical analysis, what would happen is you'd get a lot of false positives and people would be scratching their heads saying, what the heck am I supposed to do now over blocking is a traditionally difficult problem to deal with. If you look at why this isn't really quite adequate, the updates being done after files have been deleted don't quite help you get the files back. The idea is you want to make sure you don't get the files deleted from your system beforehand. Again, adequate for catching known attacks, but not necessarily sufficient for all the new attacks that are coming down the line. Well, obviously we're very good at what we do and we are able to catch a number of variations like post love letter, able to catch 31 variations following that particular virus or worm. We aren't necessarily able to predict what the next one might be like new love. Some heuristics are getting better, especially since the machines can handle it a little better today than they could in the past, but nevertheless we still have this issue of false positives. The idea of getting more reactive is actually a really good one and that's one that makes sense as well. It's a closed loop system that allows you to have something quarantine temporarily and have it inspected and analyzed in an upstream fashion so that new definitions or new updates regarding that particular bad attack can be pushed back down. This closed loop system actually makes a lot of sense. The whole point of this exercise here is to restrict the propagation. In the old days when it was sneaker net, when it was isolated to a particular land segment, we could go out and stop that segment from infecting other segments. We had human time involved. Today we don't have the human time involved so anything we can add to slow down propagation allows us to then function as humans and get back to the business of stopping these types of attacks. This series of quotes I've liked a lot. I've used it for a long time and I still use it today because it still makes sense. It's still valid. The guys over at TREM, our products are inherently reactive. The guys at Network Associates, for those who don't know, that's the McAfee guys, it's impossible to detect all the variables associated with bad attacks, malicious attacks in advance. And even my friend Cary Notchenberg over at Semantic has said we need to re-examine the way we solve this problem, this anti-virus strategy that we've been relying on for the last decade. So let's see where we're going here. We believe that the ICSA has it right. Trojans and Win32 viruses, yes guys, they're a little harder than the scripts but you've got to get into it, are going to be the way that people are going to attack systems in the future. Why? Because users can be social engineered on the network front quite easily. It's easy to get email from your boss and say this must be valid and click it and open it. And once this executable starts to launch, it has all the rights and capabilities, all the privileges you have as a user. So these things are very significant. So what do we do now? We start to look at behavior blocking technologies. We start to understand the types of behaviors that we think are undesirable, types of behaviors that we think are desirable. We want to monitor what programs are doing on the system. We want to understand where they're going, what they're trying to reach into, what they're trying to accomplish. And using that concept of behavior blocking, it is possible to stop bad things without having to rely on updates or pattern updates or definitions. This is very complimentary in fact to traditional heuristics as well as traditional pattern based antivirus. Some of the original research in this area came out of Finjon about a year and a half ago or so. And it talked about the idea that we want to intercept behaviors at the lowest level of the operating system, ring zero. And sitting as a, what some would term as a proxy between the executable that's running and the operating system in fact becomes very useful in stopping requests for operating system services that would otherwise be very nasty. So the idea is identify the operating system services that are higher risk, sit between those services and the executable, track executables as they come onto the system, understand what those executables, where those executables are spawning processes, track each of the processes, and eventually understand that the processes they've spawned may in fact be dangerous. This is a very safe way of doing it and it's very efficient because the executable actually sits way down at the operating system level. It's a very small piece of code and it's very strong against common application attacks that we've seen in the past. And likely very strong against attacks in the future. Also because it's not sitting out in the user mode, it's sitting down in the kernel, it itself happens to be a little bit more protected than an application that might sit at ring three. You force programs in this theory, in this technique to run inside of this sandbox, so to speak, by wrapping them up front and then forcing their execution through this driver. If you look at this particular log again, unrelated to the FinJohn stuff, but if you look at the type of things that you can track or that you might be looking to track, I ran or Mark ran before the executable called Pinwheel. This log is from an executable called Games and subsequently another one called Cartoon. But you can see what this particular program is trying to do.  This program probably is not going to do something good and based on that type of behavior you can then shut it down. Now what else is interesting here is that you see all the PIDs, all the process IDs that are being generated and you can actually track these back so you have a hierarchical relationship between PIDs that have been spawned by say Outlook or Lotus and see that you want to track those perhaps more with greater intent or with greater observation than you might PIDs that are spawned off of something else. We still need a lot more research in this area of executable blocking or behavior blocking. Obviously finite granularity on programs like Outlook themselves, subclassing the Outlook objects so that we get greater control over the behavior that we want to monitor. Otherwise we're going to still have the traditional problem of over blocking. We also have to understand that a lot of these things can in fact be stopped by looking at the very simple operations that scripts and other executables use. So we can stop things like Love Lugger, like Explorer Zip, fairly well and to the extent that people tend to duplicate off of existing bad code we have a good chance of stopping a lot of the repeat attacks. If we look at a narrower focus and specifically looking at the scripts again with Love Letter there were 31 variations of Love Letter and you have to be able to anticipate what those variations may do. We can look at attacks based on common vulnerabilities without the side effects of false positives or over blocking. This is really good technology for stopping traditionally script oriented attacks and a lot of those are things that we've seen in the last year or so. We can also look at the idea that instantiation of objects spawned by specific programs that are higher risk like Outlook, maybe you can throw Lotus in there as well, is in fact very important as well. I'll be able to understand where it's going. I'm going to turn it over to Mark and he's going to talk about some of the technology that he's been able to pull together in the last few months or a year. Earlier this year I was tasked with trying to address the script based alarm attacks that had started with BWAA and later achieved more fame or infamy with Love Letter and stages. So I was working on a technology which I called Gatekeeper. I wanted to eliminate the scripting engine as the vehicle that worms can attack your system primarily because when a worm is distributed as a script, you're distributing the source code and anyone with notepad can make a new variation and send it on its way. That's what we saw with Love Letter. Most of the Love Letter variations, they changed the subject line, they changed the body of the message, they didn't touch the code because most of the people making those changes didn't understand the code but they didn't need to. So script is requires a much lower level of sophistication for people to do. Microsoft is excellent at providing examples of how to do this stuff. A lot of the worms came from Microsoft sample programs. So I wanted to close that address down and make it harder for people to like these things. So we came up with a prototype technology for addressing the script based attacks. When it was done, it provided 100% protection against all of these script based attacks even though while writing it, I had never seen what these things were doing. I just knew the behaviors that they had to do in order to accomplish what they had been doing. It blocks outlook for the developers too like Melissa even though that was running as a macro inside word. Runs on all the Win32 platforms where Microsoft supports scripting. It's very low overhead. It's only brought into play when the objects that can cause damage are brought into play. And we'll be posting a working beta of this soon. It can work bundled with an AV solution. It's sort of akin to our auto protect solution. Or it could be packaged as a standalone product. I'm going into a little bit of detail about how it works. Script in and of itself can't do anything. It doesn't have any persistent storage native to the scripting interface. In order to do this, it must make use of certain objects, the window scripting host object, the file system object, and the outlook object being the most common. These objects are all known. If we limit access to the potentially dangerous aspects of these objects, we can render these scripts powerless. We do this by stealing common interfaces.  COM is a common interface with various invocation methods that can be employed. These methods cannot change as one of the rules of COM. We infiltrate this, position ourselves between the scripting engine and the COM objects, and we can then limit what they're doing. We're instantiated on demand, so we're only loaded when the potentially dangerous objects are loaded. What about good scripts? Microsoft came up with the scripting engines because it's a useful technology. If you're an admin for a large network and you need to deploy a job across your organization, script is a very useful way of doing that. Microsoft likens it to the batch files from the DOS environment, and those were very useful. These scripts will use the same objects that the malicious ones do. How do you tell the good guys from the bad guys? The only difference between a good script and a bad script is intent. And intent is very difficult to gauge. So we came up with gate key. Through gate key, we can allow an organization to sign, not digitally sign, it's not quite the same thing there, but they can indicate this script originated from within our organization, therefore it is going to be trusted. It's a companion technology to gatekeeper. This is a first generation pass at it. Ultimately, you can digitally sign the script itself and use that signature. But the mechanism is what really is being discussed here is not that it isn't spoofable, but rather that you need to have a mechanism to sign what you've created and then use that reference. The keys would be at a very small functional unit, so maybe my division has its own key for running the scripts within that. So you could spoof my key and run in my division, but as soon as I send it over to another division, it's not going to run there because it doesn't have their key. So it's designed to stop the broad based attack. Love letter went out to everybody. Anyone running script could be affected by it, but if they had been running this technology, they wouldn't have been. It communicates with gatekeeper to allow access and full functionality to the objects if the script is trusted. The administrator specifies the keys, so it protects you against external attacks. Internal ones are another issue. There's follow on technologies we could do with that, but that's beyond the scope of what we're going to talk about today. Let's talk about what actually happens in the scripting engines when you don't have gatekeeper. Wscript.exe is invoked. It then goes out and invokes the scripting engine to run the script. It passes the text to the script to be parsed and then it tells the scripting engine to execute it. While it's executing, the scripting engine will come across a create object of the file system object. That will go instantiate the file system object using common interfaces. Same thing when we do the scripting shell. When we now call open text file, we'll invoke the open text file method of the scripting object or of the file system object. Same thing is true when we go to the reg write command. Now, when we have gate key installed, when the scripting engine is loaded by Wscript, gate key gets installed first. It insinuates itself between Wscript and the scripting engine. It then gets first crack at the source of the script and it checks it to see if it contains the key. It just remembers that fact, yes, I saw the key, no, I didn't see the key, and it doesn't do anything else at this point. And we allow execution to continue. When the scripting engine goes to create the file system object, the operating system is fooled into loading gatekeeper. It then instantiates the real object. It's now, again, sitting between the scripting engine and the file system object. Same thing is true when we go and do the window scripting show. Now, when they do that open text file, we steal that interface. All the interfaces went through scripting and comm must come through a method called invoke. That's where we're sitting. We then go check with gatekeeper. We intercept the call and we go up and check with gate key to see if it saw the key. If it did see the key, everything's fine and we allow the call to go through. We're functionally invisible at this point to running without gatekeeper. Same thing true when you go through the shell object. Now, if you don't have gate key, or we didn't have the key installed, when we check with gatekeeper or gate key to see if it had the key, it's going to come back and say no. Now we block the invoke. So you can instantiate the file system object, you just can't use any of the methods on it. It's worthless. Same thing happens on the other objects that we protect. What this ultimately means is that we're pushing you toward away from scripts, because we think we have a pretty good approach to stopping those, and forcing you back into the Win32 world. Job security for the Sark guys. We have a little demonstration here. I don't know how many of you were exposed to the new love worm that came out about two weeks after Love Letter. It didn't reach wide penetration partially because it was sort of like the Ebola virus. It killed its host before it could replicate. It was very deadly. So what I'm going to do is actually run it on this machine. We say don't try this at home. Okay, now we're running in a virtual NT box. We have the new love worm, assuming it's just come into you as an attachment. So we launched the code. And we don't see anything happening. While this is running. Okay, while this thing is running in the background, we're looking at the WinNT System 32 directory. VBScript isn't the fastest executing code in the world. So it will take a little while, but the effect will be worth it. This is also on top of VM where we obviously didn't want to clobber the machine in... The bits were harmed in the making of this video. No, it's not a service. It has infiltrated the common infrastructure and gets invoked via the normal common methods. Not from within script. As I said, the point of... You would have to be executing 32-bit code in order to get around it.  You have access to the machine. So we're trying to limit the playing field and say, we're going to take VBS and JavaScript away from you. So now you have to write 32-bit code. And by that, making it raising the bar. Those are not accessible from script, except by mechanism. Here we go. Now we're seeing something. There we go. Notice all my files are changing into VBS. And if we change the view here, not only are they now all VBS, they're all zero length. So that VM environment, that machine... The Windows directory? The Windows directory was shot. And it's still off busy doing this to every file on the system. And once it finishes every file on the system, it's going to go to all your network drives and do the same thing. When I said that it killed too quickly, in a lot of cases, it sent itself along through Outlook, but it then deleted Outlook's DLLs before Outlook had a chance to actually send the message. Somebody's got to teach these guys better logic. It has that potential. In the first cut of it, I said no access whatsoever. Now I'm sitting on all the interfaces. I can not only look at the interfaces that you're calling, but I can look at the parameters at which you're calling it with. So I could say, if you want to delete a file in the temporary directory, that's fine. If you want to delete a file in the Windows system directory, that's off limits. But in, you know, development goes through stages. I said, let's start with the most restrictive and thereby easiest for me to write, because as all programmers, I'm inherently lazy. I'll put this very draconian solution in effect and see if anyone squeals. If it works, great. If we get pushback on it, we have the ability to go further down and refine these policies. The same is true of the way that we control the digital signatures. There's more intrusive methods that we could do, but they would introduce levels of complexity into the system. In the current version, a user is empowered to enable his script to run. He can physically add the key necessary to make a script run. No administrator interface is required. We could go to more restrictive models, but then if I'm a script writer in my organization and I want to write a script, I have to now submit it to somebody else to sign it and verify that it's okay before it comes back to me. That's going to be a barrier against deployment in some organizations. We'll do that if that's what they want. Now let's go to a VM running gatekeeper and see what would have happened. And this actually did happen when I received the first sample of NewLove. These VMs were stored in a suspended state, so they take a little while to come back. But not as long as booting in T4. So now we're launching the same NewLove worm. There's a lot of swapping going on here. This machine's got about 192, 256, but there's two VMs running on it. In addition to its native operating system. Okay, we run the worm now. Gatekeeper has intercepted the call. It tells you what program was executing it, what script file kind of got clipped off there was trying to execute it, what method it was trying to call and what object it was using and what method it was trying. Now you'll notice here, gatekeeper is not asking me if I want to allow this. Every user who was affected by NewLove, or by Love Letter, answered yes to the question do you want to run this? It might have a virus. Asking doesn't work. People will say yes, then they're dead. So we don't ask, we tell. Now realistic, when? Right. If they knew that it was good, they could go in and add the signature that allows it to run on that machine and then they can run the script. The end user is empowered to do that. Then they probably shouldn't be running it. Again, as Mark was alluding to earlier, the idea here is to reduce the threat, limit the propagation of malicious code as it's moving rapidly across the network. This is far from being what we would call enterprise ready or carrier class ready. This is very early stage research that we think is pretty interesting in terms of being defensive services that could be deployed. Even if they were deployed today creating a very harsh environment, or in Mark's words draconian, it would still have a very good effect in terms of pushing people away from script writing and into things that are a little bit more sophisticated with Win32 writing. These aren't in the sense of keys. We use the word very loosely. It is just basically a sequence at this point. Again, just to prove for concept, this is research. This isn't commercial product. You mentioned defending against malicious code by policy which allows malicious code that is not just a compile code, but suppose a popular workflow and a function. Then you get a kernel executing allegedly legitimate code. It's like kernel executing at that point. The question was what about a buffer overflow x point where it's not you don't know exactly who is executing the code that's been injected into the system. It would be masquerading as kernel running it. But in that case it wouldn't be kernel executing it. It would be Outlook or Outlook Express or Internet Explorer. If you have a policy in fact that says Internet Explorer is not allowed to go in and modify my Windows system directory it doesn't matter how Internet Explorer was coerced into doing that it would be stopped from doing it. Other questions The question was when I named the product Gatekeeper or the project Gatekeeper did I make allusions to the movie The Net where they actually created viruses in order to get people to install antivirus software which was actually the real virus. No. I just came up with a name. Actually the name is not fixed yet. This is the working title of it. The final name not determined yet. Market texture folks what's it? Not based on Ghostbuster. If you really think about it it's a gate and it's keeping out scripts. It's a fairly simple concept. Again this is an internal code name kind of like Whistler with Microsoft guys and it's not the final name. I work for Symantec. As quickly as I can get it up there. This will be out there and available for download and your comments would be great. RTS format. I can't say that about any other scale. 10 years. It's imported by everything. It's very simple and it works. Why are we continually trying to make a broken system that still work when bottom line nobody uses scripts? Well what you're talking about is Mac does not scripts. Mac does not scripts. Nobody uses it. As any query I'm going to show is actually the same. Say maybe 1% of the actual script usage is not the way that it's happening. A lot of it depends on the organization with which you work. There are corporations that we deal with where scripting is a way of life and disabling it is just simply not an option for them. Let me give you a better example of the type of things that are happening in corporate settings. There is a capability inside Excel to call programs outside of Excel in order to execute programs and bring in their resulting data back into the Excel spreadsheet. You kind of look at that and say that's pretty far-fetched. Most people in fact don't use that function. But if you go into financial organizations they actually have very complicated spreadsheets that take advantage of these invocations to bring things in. So now if you actually think of a spreadsheet as a carrier of malicious code you could actually let's call it ASCII executable stuff sitting in an Excel spreadsheet that you can save and then execute from the same Excel spreadsheet. That Excel spreadsheet can be moved over the web from one point to the next and as soon as it comes on board because of the way the Windows operating system is configured it will automatically associate the XLS object with the Excel application, launch the Excel application in the background because your browser is still the primary and allow this thing to then take off. Now the response on the Microsoft end was what we're going to remove this function. Well that's really going to your concept of let's remove Word document functionality, let's go to RTF. Well the reality is there are corporations that rely on this functionality that can't eliminate it. This is something IT has to improve because honestly what you're ending up with is individual users having to keep building and distributing stuff that they have no idea of what they're doing because they're not qualified to be doing what they're doing and here we are wondering why our levels are improving. Well I mean you can translate that to the entire web infrastructure saying those who are developing web services, forget about documents and Excel spreadsheets, look at the web services that are being developed. They're not always being developed by people with understanding of how programs may affect people downstream. The unintentional use of some software is usually what is exploited. It's not the intentional use, the intentional use is usually well thought out. But it's the unintentional side effects of a program that can be used to buffer overflow concepts and things like that. And so if you look at that really the problem is that we just have a lot of people writing code and that's not going to change. And so you're going to expect various quality in the code that's being pushed to you and therefore you're going to need some type of defensive infrastructure to protect you against anything that may be coming at you. Other questions? We've got some time I think or not. One more question if there's any. I can't hear you. Do you want to repeat the question? What was the extension you put on it? The question was what if somebody makes a batch file that goes in and modifies the registry in such a way to allow the batch file to execute script? Is that what you're getting at? Potentially that's possible. As far as gatekeeper is concerned... This may not sound like a real satisfactory answer to you at this point, but that is not a script based attack at that point. It's a batch attack. We have other technology that we're working on that will address the problems that go beyond script. Part of it also the reason that Love Letter was so successful is that people had never seen a VBS extension. A lot of people have been sensitized about finding X's that they receive. Batch files also to a degree that were recognized as executable, but VBS I've never seen this thing before. Maybe it's a picture. I don't know. I'll open it. Alright. We'll be around the rest of the week. Thanks for your time today and catch up with you later.


My name is Amy Wobello, I'm a sailor HG on the Internet, and a little bit about myself. I recently started my own publishing company to write computer science scenes for high school age students and make computer science more accessible through drawings and comics and stories, and I left my job as a developer at Airbnb to be able to do this full time. If you care about CS education and want to come talk to me about this afterwards, I'd be super happy to talk to you. And today, I'm going to talk to you about knitting. All stories start with an inspiration, and here's mine. A few years ago, a video game review site called Kotaku published an article about Nintendo add-ons that didn't quite make the cut. You might here have heard of some of the peripherals that did make the cut, a baseball add-on to play baseball video games, a golf add-on to play golf games, a super scope for shooting games, but you might not have known that Nintendo was seriously contemplating making a knitting add-on. And this is the proposed advertisement for the knitting add-on, complete with bad puns. I'm not sure if you can read it, but in the right corner, it says, why needle the competition? So the interface would be just like Mario Paint, but instead of seeing what you drew on a screen, it would also knit what you had drawn onto a sweater or mittens or a scarf. Most of the comments left on the Kotaku article were along the lines of, lol, we can see why this one never made it to production. But I had a totally different reaction. I was so sad and heartbroken. I had never wanted so badly for something to exist in my life. So I did research. Didn't Nintendo make any prototypes that I could get my hands on? Did anyone else make home knitting machines that I could use? And it turned out that in the 1980s, there were a bunch of companies that made home knitting machines, but they weren't very popular, so they stopped making them. And that's when my dream was born to get hold of one of these old machines and to hack it to make the Nintendo add-on that never was. As fate would have it, there was one of these super old knitting machines for sale on Craigslist, an hour and a half drive from where I live. So I went to pick it up, and it was broken and parts were missing, but it was a start. It was a start of my dream, and I was really excited about it. And this is to reiterate the dream, again, in cartoon form, to be able to take pictures, to send them to a knitting machine, and to end up with sweaters. Basically to create a networked yarn printer.  It has 200 needles that move an out, and you can thread up to two different colors of yarn to create patterns. And if this is what using a knitting machine looks like, this is what using a knitting machine feels like. And I was worried that if I pressed the wrong thing that this would happen. Or at least that I would break some of the needles and have no idea how to fix it. Luckily I had a team of people to help me face this challenge that was both fearless and inventive. I had a team of Airbnb engineers that helped me hack the knitting machine for an Airbnb hackathon. Airbnb hosts internal hackathons twice a year for the entire product team, including engineers and designers. And so many different kinds of engineers signed up to work with me on this project.  But all of my teammates were super amazing, and this was probably one of the best teams that I've ever worked on in my life. And I think that partly it was because we all had zero ego attached to knitting. This was just kind of a wild adventure that we were all in together. So after we set up the knitting machine and were able to successfully knit rows of solid color, the next step was to learn how to use the machine to knit patterns. And even though this was something that was already built into the machine, it was twice as complicated as our first goal, because there was twice as much yarn to get tangled and 50 more pages of the knitting machine manual to read about how to set it up. And just to show you how non-trivial this step was, on the left is our first attempt at knitting one of the built-in patterns. And then many hours later, you can see that the polka dots that they were supposed to be. But after we had figured out how to use the knitting machines built in patterns, it still wasn't quite our dream yet. As far as we could tell, the intended user of a knitting machine was a grandma in the 80s, because all of the patterns that they had available were like polka dots, bows, teddy bears, roses. And I don't know about you, but I would much rather have a sweater with grumpy cat on it than a teddy bear. So we're still important to us to figure out how to send the knitting machine our own images, which is step three of our goal. And this goal would be split up into several parts. So because it's from the 80s, the knitting machine took additional patterns via a floppy drive. And you could buy floppy disks that had additional patterns to upload to the machine. So we can emulate a floppy drive in software and send that fake floppy drive our images. And then we would need to build a custom cable, one that would have connected the knitting machine to the floppy drive, but would instead now connect the knitting machine to our computer. So it would be serial to USB. And we had to custom make this, because the knitting machine had a really weird pinout. And luckily, we found documentation about that. Then we had to convert all of our input images into low res 1-bit maps, because that is what the knitting machine took as its file format. So here's one of our first custom patterns. And here's floppy cats. So by this time, we were having entirely too much fun with this knitting machine, but we thought that we might be hogging the fun. We didn't want sending pictures to the knitting machine to be limited to just us. We wanted anybody in the office to be able to do it. So the next step was to make knitting machine image upload available on the web. And it would be a super simple interface. You'd choose a photo to upload, and then you'd send the image to the machine. And it would print out instructions for which buttons on the knitting machine you should be pressing in case you would never used it before. And here's a video of it in action. And I don't know if I have the audio hooked up. So we wrapped the library that converts the image into a one bit bit map, and we call that knitting pattern. And there's also a wrapper for the floppy disk library that we found, and we called it pattern disk drive. And when the user presses the upload button, we save the user's image to a file, use the image processing library to convert the image to a one bit bit map, and then we start emulating the floppy disk drive. And then in the browser, we display instructions for the user for which buttons they should be pressing on the knitting machine. So things that we learned from this adventure.  Another learning is that teams work really well when they operate with zero ego at stake. Also, it's really enjoyable to apply Ruby to any of your hobbies no matter how unrelated they might seem. And then the last learning is that it feels really great to take up something that you know absolutely nothing about. Learning something brand new and very different from what you do day to day is really humbling and challenging, and it's refreshing. And it reminds you what it's like to be a beginner, which is important to gain empathy with new programmers that you might work with or teach or mentor. And the epilogue of this story is that we eventually got good enough at using the machine to be able to knit full sweaters with our designs on them. And here is a doge sweater, which I also brought today. And lastly, I would love to talk to you about ideas if you care about hardware hacking, combining code with art, and about CS education. Thank you for listening, and thank you so much for having me.


CC's decision to to throw it on there Do I You're awfully Assumptive there.  That's what really gets you.  I hated it Why did he explain to the warnings to you or how did he explain who was it? I actually didn't know there was warnings right after because I was so mad at you know Seeing row get dropped like that, you know, so my first concern was just you know frustration and making sure he was okay I actually didn't know the warnings. I know when Cece he walked out He said something and and Vic was clear that he did issue the warnings So Yeah, I wasn't even aware At first of the warnings, but I was just trying to you know, just kind of reconcile You know them throwing it row like they did so I'm sorry. Just be clear.  I mean that's again I think we're just assuming that everything unfolded the way it did and you know, I I'm just I'm just glad Rose. Okay through all this As he walked off the mound, he mouthed something at the raise dugout So them yelling at him like, you know when when it happened. So, you know chicken in the egg, right? Are you worried at all in that like in that moment that it? Escalates to something else where somebody can get absolutely and it you know and especially this time of year Yeah, I mean that's that's the thing you worry about and obviously right now we have a lot at stake and Last thing we want to do is you know get guys in trouble or get guys more importantly get guys hurt Did you on your way out? Do you convey that message or is that just something that everybody knows or yeah? Yeah, we'll have a clear clear message Yeah, that was probably wanted Cece's better games too. I mean he was he was cruising in that And yeah, so he had a lot of stake in the way that he had been pitching as well I think what gets lost in all of it is how well he threw the ball and His slider was terrific today. I mean he had it at will back door The cutter, you know, which is which has been a little spotty for him.


From Cambridge, Massachusetts, it's The Cube, covering MIT Chief Data Officer and Information Quality Symposium 2019, brought to you by SiliconANGLE Media. Welcome back, we're here to wrap up the MIT Chief Data Officer Information Quality, it's hashtag MITCDOIQ conference. You're watching The Cube. I'm Dave Vellante and Paul Gilan is my co-host. This is two days of coverage. We're wrapping up, this is our analysis of what's gone on here. Paul, let me kick it off. When we first started here, we talked about at our open, it was, we saw the Chief Data Officer role emerge from the back office, the information quality role. When in 2013, the CDOs that we talked to, when we asked them what was their scope, we heard things like, oh, it's very wide, involves analytics, data science, some CDOs even said, oh yeah, security is actually part of our purview because all the cyber data, and so very, very wide scope. Even in some cases, some of the digital initiatives were sort of being claimed, the CDOs were staking their claim. The reality was, the CDO also emerged out of highly regulated industries, financial services, healthcare, government, and it really was this kind of wonky back office role, and so that's what it's become. And it's what it's become again. We're seeing that CDOs largely are not involved in a lot of the emerging AI initiatives. That's what we heard sort of anecdotally talking to various folks. At the same time, I feel as though the CDO role has been more fossilized than it was before. We used to ask, is this role going to be around anymore? We had CIOs tell us that the CIO role was going to disappear, so you had both ends of the spectrum, but I feel as though that whatever it's called, CDO, data czar, chief analytics officer, head of data, analytics and governance, that role is here to stay, at least for a fair amount of time. And increasingly, issues of privacy and governance and at least the periphery of security are going to be supported by that CDO role. So that's kind of take away number one. Let me get your thoughts. I think there's a maturity process going on here. And what we saw really in 2016 through 2018 was sort of a celebration of the arrival of the CDO. And we're here, we've got power now, we've got an agenda. And that was a natural outcome of all this growth and 90% of organizations putting CDOs in place. I think what you're seeing now is a realization that oh my God, this is a mess. And what I heard this year was a lot less of this sort of crowing about the ascendance of CDOs and more about we've got a big integration problem, a big data cleansing problem, and we've got to get our hands down into the nitty gritty. And when you talk about, as you said, we hadn't hear so much this year about strategic initiatives about artificial intelligence, about getting involved in digital business or customer experience transformation. What we heard this year was about cleaning up data, finding the data that you've got, organizing it, applying metadata to it, just getting it in shape to do something with it. There's nothing wrong with that. I just think it's part of the natural maturation process. Organizations now have to go through to the dirty process of cleaning up this data before they can get to the next stage, which was a couple of three years out for most of it. Yeah, the second big theme, of course, we heard this from the former head of analytics at GSK on the opening keynote, is the traditional methods have failed. The enterprise data warehouse, and we've actually studied this a lot. My analogy is I often use snakes swallowing a basketball, having to build cubes. EDW practitioners would always, I used to call it chasing the chips until we'd come out with a new chip. Oh, we need that because we got to run faster because it's taking us hours and hours, weeks, days to run these analytics. So that really was not an agile, it was a rear view mirror looking thing. And Sarbanes actually saved the EDW business because reporting became part of compliance. The master data management piece, we've heard, you consistently, we've heard Mike Stonebreaker, who's obviously a technology visionary who was right on, it doesn't scale. This notion of de-duping everything just doesn't work and manually creating rules, it's just not the right approach. We also heard the top-down enterprise data model, doesn't work, it's too complicated, can't operationalize it. So what they do, they kick the can to governance. Hadoop was kind of a sidecar there, big data. That failed to live up to its promises. And so it's a big question as to whether or not AI will bring that level of automation. We heard from KPMG, certainly Mike Stonebreaker again said, and we heard this as well from Andy Palmer. They're using technology to automate and scale that the number one data science problem, which is they spend all their time wrangling data. You know, we'll see if that actually lives up to its promise. Well something we did hear today from several of our guests was about the promise of machine learning to automate this data cleanup process. And as Mark Ramsey kicked off the conference saying that all of these efforts to standardize data have failed in the past, this does look, he then showed how GSK had used some of the tools that were represented here using machine learning to actually clean up the data at GSK. So there is, and I heard today, a lot of optimism from the people we talked to about the capability of Chris, for example, talking about the capability of machine learning to bring some order to solve this scale problem. Because really, organizing data, creating enterprise data models is a scale problem. And the only way you can solve that is with automation. Like Mike Stonebreaker is right on top of that. So there was optimism at this event. There was kind of an ooh, kind of a dismay at seeing all the data problems they have to clean up, but also promise that tools are on the way that can do that. Yeah, the reason I'm an optimist about this role is because data is such a hard problem. While there is that feeling of, wow, this is really a challenge, there's a lot of smart people here who are up for the challenge and have the DNA for it. So the role, that whole 360 thing we talked about, the traditional methods kind of failing, and then the third piece I touched on, which is really bringing machine intelligence to the table. We haven't heard that as much at this event. It's now front and center. It's just another example of AI injecting itself into virtually every aspect, every corner of the industry. And again, I often joke, you know, same wine, new bottle. You know, our industry has a habit of doing that. But it's cyclical. But it is, but we seem to be making consistent progress. And the machine learning, I thought it was interesting, several of our guests spoke to machine learning being applied to the plumbing projects right now, to cleaning up data. Those are really self-contained projects. You can manage those, you can determine test outcomes, you can vet the quality of the algorithms.  They're vetting, they're burning in machine learning in an environment that they can control. Right, so anyway, two solid days here. I think that this conference has really grown. When we first started here, it was about 130 people, I think. Right. And now it's 500 registrants this year. I think 600 is the sort of the goal for next year of moving venues. The Cube has been covering this all but one year since 2013. I hope to continue to do that. Paul, it was great working with you. Always great work with you, Dave. We could do more together. We're here at the Vertica's bringing back its conference, you and I did that together. So we had Colin Mahoney on.  Colin Mahoney, Mike Stonebreaker, Andy Palmer, and Chris Lynch, all kind of weighed in, which was great to get their perspectives into the days of MPP and how that's evolved, improving on traditional relational database and now, of course, Stonebreaker applying all these MI, same thing with AtScale, with Chris Lynch. So it was fun to watch those guys all Boston-based, East Coast folks. Some news, we just saw the news hit. President Trump holding up the Jedi contract as we've talked about. We've been following that story very closely. I've got some concerns over that. I think it's largely because he doesn't like Bezos. And the Washington Post. And the Washington Post, exactly. Here's this, America first. If the Pentagon says they need this to be competitive with China and AI, there's maybe some, where there's smoke, there's fire there. It's more important to stick it to Jeff Bezos. That's what it seems like. So we're watching that story very closely. I think it's a bad move for the executive branch to be involved in those types of decisions, but what do I know? Well, anyway, Paul, awesome working with you guys. Thanks, Andrew, appreciate you flying out. Sal, good job, Alex, Mike. Great team. Already wrapping up. So thank you for watching. Go to siliconangle.com for all the news. YouTube.com slash Silicon Angles, where we house our playlist. But theCUBE.net is the main site where we have all the events. It'll show you what's coming up next. We've got a bunch of stuff going on straight through the summer. And then of course, you know, VMworld is the big kickoff for the fall season. Go to wikibon.com for all the research. We're out. Thanks for watching Dave Vellante for Paul Gillan. We'll see you next time.


Really I just I would try to defend her. I would bring all the courage I have in me and just try to stand up for them and for the children as well and I think I would also tell and say to Zaynab to stay strong for the children as well and tell her and remind her about What God has written in the Quran about patience and That he really has given this fight for his strongest warriors I would keep reminding her that because I want her to stay strong for them and for Everyone to show that yes, she's a woman. She's a woman and Yes, she's lost everyone. She's lost her mother her father her grandfather her brothers But she still has this patient and patients in her