Welcome to today's presentation, where we'll discuss records, rewards, and risks of using this technology. I'm very happy to have Dara Perry, Dr. of course Pat Franks, and Amitabh here today to talk to us about blockchain and records management. I hope the takeaway today for all of you is to get not only an introduction to this, but also go into that 201 level, even 301 level of the blockchain technology, but also be left with a lot of resources that are out. So we've got Dara Hoffman, she's an incoming assistant professor, and just recently completed her PhD, congratulations. She is a professor for the School of Information San Jose State University. So with us is, I'm sorry, Dara, you reside in British Columbia, correct? Yes. Okay. South of Vancouver. South of Vancouver, excellent. Also we have Perry J. Swift, she's the university records manager at The Ohio State University. Even though I come from the state of Michigan, I'm happy to have her here, and I'm a Notre Dame fan, so it really doesn't bother me in regard to the Michigan State, Ohio State rivalry, although it seems like Ohio State is definitely, at least in the sport of football, American football, they've had our number. Very true. Dr. Pat Franks, professor and Mara program coordinator, School of Information at San Jose State University. She's also an author of Records Information Management, her second edition book was recently released. There is a review on IG Guru for those who are interested in picking up a copy of her book, and who is very, she's very much responsible for putting a lot of this content together and will later reference the white paper. And Amitabh Shivastav, you have Operations and Governance at Helix. And I skipped over Perry, referenced Ohio, you live in Ohio. Amitabh, you live in Toronto, if I'm not mistaken, correct? No, I live in Ottawa, Canada, so a little bit more east of Toronto, kind of midway between Toronto and Montreal. Ottawa, that's right. Yeah. Careful, yeah. Sorry, my American is shown there, I apologize. That's okay, no problem. I apologize. So blockchain technology, industry use cases, RIM challenges and the unknowns, risk audit and considerations are going to be covered today. I'm listed as the moderator, but I'm not really going to moderate anything. Each of the presenters has a presentation they're going to give, that's a short presentation on these sections. And if I'm not mistaken, we are going to be taking questions at the end. So if you could please hold your questions till then or type your questions in the chat box and then we'll answer them at the end and we'll have that specific speaker, presenter and or others chime in. So without further ado, we can go ahead and advance the slide and have Dr. Dara start. You could take it away. So good morning everyone. I get the honor of starting and explaining what blockchain is. And so this is a 25,000 feet view. There are people who write lengthy papers full of math equations and pseudocode about every tiny technical aspect of different types of blockchains. That's not me. I am your, you know, classic liberal arts fluffy type. And so we'll be talking, I'll talk about it from a very high level, what this is and how it works. So this is the Interparis, which is an archival research group definition. The ISO is working on their standard for blockchain and that will probably become the accepted definition, but it's not out yet. But blockchain is basically a trusted and mutable ledger of transactions that's decentralized and distributed. So I'm going to kind of talk about each of those aspects in turn. So let's start with ledgers. I think most of us who are archivists, records managers, we're all familiar with ledgers. Even people who aren't necessarily in the archival field still have a vague sense. Ledger is just basically a collection of related transactions. And that related transactions part is important because once you start throwing the whole kitchen sink into a ledger, you lose that sense of connection, you lose the sense of relatedness and it becomes a lot harder to make the ledger serve its purpose. Which is one of the problems of blockchains that try to do too much is that you lose the ability to form the connections between the record and to maintain what archivists would call the archival bond. So we've got a ledger. So how is this different from any other ledger? This picture you'll see almost anyone who talks about blockchain present. But it's not a blockchain picture. It actually comes from a rant study back in the 1960s or 50s about nuclear war. And what the picture represents is how we can make communication systems more robust in the event of a nuclear attack. And so you see the first picture here on the left, that is a centralized system. All you need is one nuke to take everybody down in that way. Then you have a decentralized system where there are more than one controlling nodes. But you still only need to take sevens down. Whereas when you have a distributed network like you have on the right, the idea is that all that redundancy, having all these different nodes in communication with one another leads to a lot of robustness and it makes it a lot harder to destroy the system just by destroying one, two, or even seven nodes. And so you see the same idea at play behind the distributed network in the blockchain. Because by having lots of nodes in contact with one another, you can't just take down the whole system by taking down one node. And so for example, you see people who advocate the use of blockchains to prevent censorship. This is part of the reason. Even if repressive regime A takes down all the nodes in their country, the resistance can still be communicating using nodes outside the country, for example. And so this distributed network is a really important part of how blockchains are built. Now then, a big buzzword in the blockchain world is immutability. Immutability is the idea that once something goes onto the blockchain, it can't be changed. And the reason the blockchains are supposed to be immutable is because the way that they work is basically I have a transaction. I'm going to buy something from Dr. Pat. And so before that transaction gets written on the ledger, someone, let's say Andrew, is going to check to make sure that Pat has the 20 bucks and I have, or I have the 20 bucks that I'm offering Pat and Pat has the shirt in her inventory. The transaction then gets verified and gets written onto the, onto a block. And then you get a block of 10 transactions. And so each of those transactions has a fingerprint taken. And every single fingerprint, and that fingerprint is actually an alphanumeric code that's done through an algorithm, but you have a block with 10 fingerprints. The very first fingerprint of the next block is going to be all 10 of those hashed together into a handprint. The hash is the name for the fingerprints. And so if I change something in block one, if I change the fingerprint for mine and Pat's transaction, then the fingerprint in block two is going to be wrong as well. And so that's the idea behind blockchain immutability is that each block is chained together with that previous hash with those previous fingerprints. Now then blockchains are theoretically immutable to certain attacks like a 51% attack for the Bitcoin blockchain. If I control 51% of those nodes that I showed you in the distributed chain, then I can change all of the transactions that I want and no one can check me and no one can catch me. So I prefer to say that the blockchain is highly tamper-resistant as opposed to immutable. That said, it's a highly evolving space. There are lots of different types of blockchains and their technology, the technology is advancing rapidly. But as it stands right now, I would say most blockchains are tamper-resistant. And tamper-resistance is both a strength and a weakness because, of course, if you make an error, it can be very challenging to correct the record if the record is on chain. You basically have to create a new record. So it's an interesting space for us as researchers, especially as archivists. Now then disintermediation. This is one of the really interesting things about the blockchains. And this is specifically in what you would call a public permissionless blockchain is where this is the strongest. And that means it's a blockchain that anyone can use and that no one has special permissions different rights on. There are other types of blockchains where you do, for example, have people with certain rights like voting rights or where the blockchain is only accessible to certain people. We see those, for example, in medical research or in certain financial areas where we want higher degrees of protection. But the idea of disintermediation is that instead of asking a lawyer or a banker or some trusted party, some trusted entity to intervene in transactions, the blockchain itself does it. So in the Bitcoin blockchain, you have a consent mechanism whereby people can mine and whoever solves the cryptographic puzzle first gets to check mine and Pat's transaction to see if it's good. And it all happens without direct human intervention. That's the idea behind disintermediation. But of course, into the intermediation, again, you see this jainist like coin throughout blockchain technology because if there's no intermediary, then who's responsible if things go wrong? The blockchain is this interesting thing, especially the public permissionless blockchains that seems to be owned by everyone and no one, which makes it a very fascinating space for, from a legal perspective, which is by past life before I came into archives. And so where does liability fall when something gets messed up? Who's responsible, for example, if a court finds that there is personally identifiable information or incorrect information on a blockchain that needs to be redacted in subway? Who's responsible for making that happen? If you don't have any particular intermediary to point to someone who's legally responsible, it's a really challenging question to deal with. And we see this, I'm sure, I think, Pari's going to talk about this later, but with the new general data protection regulation out of Europe that the huge privacy regulation that came out two years ago, there's a lot of big questions about how to manage blockchains in the existing legal frameworks. So this is basically a nice picture from this about how it actually works. So the hash there is the fingerprint I was talking about. The algorithm runs over the transaction. If you change a bit, you change the hash, it's 256 alphanumeric characters. A timestamp is exactly when it happened. Nonsense is a little bit of nonsense. And then, of course, the hash is the block data. And you see that each of these blocks is chained together with the hashes from the previous blocks and hence the clever name of block chain. So really one of the big things the block chain is meant to deal with is this question of trust. The idea behind the block chain is Satoshi's White Paper, which only in 2009, which might seem very long ago to some of you, but it's quite recent in terms of technology. The idea was to create a cryptocurrency that could be used between parties who don't know each other, don't trust each other without third party intervention. And so it's really a big question of trust. We can't trust people, so we're going to trust the technology because there's this idea that technology doesn't buy, technology isn't buy, as technology doesn't have interests. And so you see this idea too, even in the archival field, you know, we have this idea of neutral third parties, trustworthiness, blah, blah, blah. And so the idea becomes that people can't be neutral, but maybe a machine or mathematics can't be. So does that mean all of our trust problems are solved? Nope, not so much. What it comes down to, and you're seeing this a lot, for example, in the research about accountable AIs, for example, to bring another technology in, is that we have a lot of problems with trust and with bias and with neutrality that still haven't been dealt with, even with the blockchain. That said, it's a fascinating technology with lots of possibilities that I will now turn it over to my colleagues to explain and to discuss. Thank you. This slide, real quick, is it's an ontology of records, trustworthiness, that Dr. Victoria Lemieux, who heads a blockchain at the University of British Columbia, based on an ontology of trustworthiness that Interparis came up with, because when we talk about trusting records, we talk about free things, accuracy, reliability, and authenticity. And while blockchain is fantastic at ensuring the integrity of the records, for example, if you're hashing records that happen off the chain, there's nothing that a blockchain can do to make those records reliable. They were either reliable or not before they got hashed in the chain. And so it's just an example of all the work that still needs to be done in the space with this technology to meet our needs for reliability and trustworthiness. And that's all I got to say about that. All right, industry use cases, and we're on slide number one for you. Go ahead. Excellent. OK, so the first challenge, I think, in deciding if a blockchain is the right solution for you is to take a look at some of the use cases. And we see a number of use cases that are here, including credit history elections, health care, and so on. So this matrix you may have seen quite a bit, and it explains the questions that you have to ask yourself and then answer if you're an organization to decide if you think the blockchain is the right solution. On the left hand side, and I won't spend a lot of time on this, but there are three questions that are important. Do you need a shared database for multiple users? Do you need it to be immutable, time stamped and keep a log of all entries? And do you have trust issues among the users? If all of those answers or any of them are no, you might want to think about perhaps finding a way to use a traditional database. But if those answers are yes, then you want to move on to the right hand side of that matrix where you ask yourself, will any of the data stored need to be modified or deleted in the future? You heard Dara talk about the GDPR and the fact that some information may have to be deleted. Will personal and or sensitive data be stored that you want to be sure is not revealed? Will big data be stored? If any of those answers are yes, you might want to consider other solutions, but it doesn't mean the blockchain is not right. It may mean that you would store a hash of the data on the chain and then you would store the data itself off the chain. If the answers are no, then it's pretty evident that the blockchain may be right for you. So I want you to keep this in mind. It's a quadrant and I'm taking a look at two different issues here. One is the public and private modality. Who can write or create on the blockchain? All right. Is it just certain people who have permission? If so, then it would be private. But if it's anybody out in the public, then of course it's going to be public. But what about the reading and consuming? Is that different? It may very well be. It may be that only certain people can read the information that's on the blockchain or everybody can. I want you to think about this acronym that databases can be used to describe a database. It's CRUD. Have you heard that CRUD? It means create and read and modify, update, by updating or deleting. So you have your CRUD, create, read, update and delete. That's a database, but a blockchain can't do all of that. A blockchain can only do the create and the read. That's all you're thinking about here. So that's the difference between the two different types of technologies. Keep this in mind. Maybe draw yourself a little rectangle with four blocks. And then I'm going to go quickly over four different use cases. And then I'm going to see if you could put them in the right quadrants there. So the first use case is e-voting. And I thought this would be interesting because we're all concerned about voting right now with the presidential elections coming up. And West Virginia back in 2018 tried a blockchain voting in their midterm elections. They used Votaz, which is a mobile voting system platform. And they thought it was successful as did an independent group that took a look at the results. However, recently there was another study that said maybe this can be violated in some way, not necessarily the blockchain layer, but other aspects of it. So they're not sure that they're going to be using that for the presidential election. But what the idea was there is that it would be really good for our military personnel stationed overseas. They would be able to use their mobile devices in order to register and in order to vote. Denver used it for their municipal election as well. And they thought it was quite successful as did an independent study show that it was very useful for them. That was the second pilot using the same system Votaz. Now, what about blockchain for the presidential election then? Well, I like this little bit of a headline here. Does Trump know that blockchain is nominating him? What they really mean is that two states, Utah and Arizona, use blockchain to select the delegates who are going to go to the convention in August and nominate President Donald Trump for his reelection bid. So the third is gambling. And I don't know if you enjoy going to casinos. My husband does, so I frequent casinos. And the idea there is that everybody, if they're of age, should be able to gamble to visit a casino. But there's always a question about the house payoff. You know, is that really legit? What's happening behind the scenes? And the same thing goes with our quick draw or whatever the states may be doing for lotteries. We want to know what's the percentage payout. Well, blockchain can be used for gambling. And you see here that it even can be integrated with virtual reality. So you have the whole feel of going into a casino to do your gambling. And we see a couple of examples of blockchain technology used for gambling or gaming right here on this slide. So that's our third example. And then our fourth, well, actually I guess our third supply chain. In the wake of the Romain, do you remember this E. coli scare where leafy green Romain lettuce was the cause of E. coli? And they were trying to trace this back to the source. You know, what happened along the way that would cause this problem? And where did this lettuce come from? It's very difficult to figure that out when you have to trace back the supply chain. So Walmart decided that they were going to experiment with blockchain technology in order to follow the chain of supply for their leafy green vegetables. And they did a two year pilot and as part of it, they tried to trace back the source of sliced mangoes of all things. And it took seven days for Walmart employees to locate the farm in Mexico that grew the fruit. So seven days after the first thought that they should trace this back. However, using IBM's blockchain, they were able to trace this back in a matter of seconds. Big difference. So now you would be able to know exactly which greens were contaminated, where they came from. And if customers knew this, they would be able to check too to see if they were in danger or if they had to discard what they had purchased. So the last one is law enforcement. So blockchain can be used for law enforcement, but for a lot of different reasons. I'm just showing one here, but it could be used to spot crypto crime, to standardize distributed crime reports, to secure interoperable interagency data sharing. The illustration that is used here is that blockchain can be used for keeping track of evidence. So a tamper-proof chain of evidence for law enforcement. And in this case, we're using one of us a different type of blockchain solution in order to provide this service. So, okay, we get back to this little quadrants again, and we can think about the four different examples that I gave you. So let's think about that very first one and see if you were correct. In voting, we want everyone to vote, right? But really, does everybody see that vote? I don't think so, even as far as the documents that were used. If you were using paper in order to vote or the OCR scans or whatever may be, we have election officials that are privy to that information and just give us the results. So where would our voting come into play on this quadrants? All right, so it would be public for writing, but it would be closed for reading, okay? The next example that we had was the gambling. So I mentioned everybody should be able to gamble if they're of age and if they would like to do that. But at the same time, everybody would like to make sure that they could see the payoff stats that they know that the system is transparent. So what does this mean as far as creating and reading the information? Gambling, all right? So in this case, writing is public. We can all take part in this if we'd like. And then reading is also open so that we can see the type of statistics, the payout that is happening with the gambling that's going on. All right, the next example was the supply chain with those leafy green vegetables going from seed all the way to your table. In this case, only those that are involved in the supply chain should really be writing to it. So the distributors, the growers, whoever that may be. But all of us would like to know where the heck that came from if there is a scare. We want to be able to find a way to trace back what we have purchased and the brokers would like to do the same so that they can see if this is part of that contaminated batch or not. So there you go, your supply chain is private as far as writing, but it's open as far as reading. And that leaves us with the last quadrant, which is going to be our law enforcement. When I think law enforcement, I think secret, right? We want to write and make sure our records are secured. Not everybody can see them. And at the same time, we want to only have certain permissioned people read the information that's there. So I'm wondering how you all did, if you were able to figure that out. And I want to thank you for your attention. And now I'd like to turn this over to Pari Swift. The University Records Manager at Ohio State and Pari, go ahead. Thanks, Pat. Well, one of the questions that I saw come in was how each of us got involved in blockchain and I got involved in blockchain because as a records manager, I feel like I needed to know enough about it in order to be able to have the conversations and be involved in the conversations with the IT teams and other teams involved in it. And I think that I soon realized that I didn't understand it at all. And what I thought I understood was wrong. So that's how I got involved. So that I made sure that I knew enough about it to have those conversations that I was able to clear up what I was misunderstanding about blockchain. And that is why I have the records, new information, management challenges and unknowns because currently, while we're starting to understand blockchain, we don't know much about how records management is going to work with blockchain, nor do we have a lot of case law on how blockchain is going to stand up to legal standards and challenges. Records and information management teams are often not consulted when it comes to IT projects, not just blockchain projects, all IT projects. So it may be that we're not even going to be aware when our organization is considering blockchain. However, system design can really impact the records management functions within blockchain, whether it's private, whether it's public, understanding where documents related to the transactions on a blockchain are stored is very important, especially if they're not on the blockchain, if they're somewhere else. So records management should not just be a part of the project team working on just the system design, but it should also be represented in change management. Change management is also one of those functions that's often led by IT when, in fact, it's the records professionals that have a deep understanding of how people's records creation and records keeping practices are going to be impacted by whatever the new system is. If you can go ahead and click, not only, if we go back, I'm sorry, I have animations in line. So blockchain projects are often pre-cited without consulting records management on whether the records or the data or the transactions are an appropriate use or whether blockchain is an appropriate use for those things. Oftentimes, the project and the solution go hand in hand. Somebody is going to come and say, we want to do this project using the solution and minds are made up before that analysis even takes place. And then, unfortunately, sometimes records management is seen as throwing up roadblocks to these projects. We're slowing it down. But really what we want to do is make sure that that it's going to work not just for the business unit's present functions, but that we're going to be able to comply with records and information management laws. So one thing in particular, we want to make sure, as was already mentioned, that personally identifiable information is not held within the blockchain. So while the basic definition of a record is the same across the board, whether it's an ARMA or SAA dictionary or other standards or even state and federal law, the components that make up what a record is can vary across jurisdictions. And so that's something that we have to deal with. We have to figure out, you know, in our jurisdiction, is metadata considered a part of the record or a separate record in and of itself? Do multiple documents or pieces and parts make up a single record? Or is each one of those a different record? And again, this is all going to depend on the definition of record in your jurisdiction. And can those different portions have different records management requirements? I have spent my entire 20-year career in government at all levels. So accessibility is something that's incredibly important to me, whether it's FOIA or public records requests or even eDiscovery and just discovery. So in the case of blockchain, are those pieces and parts, are they stored in other places? And how does that implement disposition? How does it affect how we get access to those records? You know, we have to take into consideration, is there an encryption key that certain people need to have, whether it's the attorneys in your litigation division or anybody who's responding to public records requests? Are we going to have that encryption key or are we always going to have it? And then there's the lack of classification within blockchain. Are we going to easily be able to locate and provide access to the information that's being requested? And again, this goes back to how are specific state or federal laws when it comes to access worded. Each of those could be different. And then do we have the ability to redact if we need to redact in a situation like that? Is blockchain going to give us that ability? So one of the challenges in records management in blockchain is retention and dispensable disposition. We want, you know, we always learn in records management. We want to make sure that we get rid of records for retention schedules. And sometimes we, there's a liability if we don't. It can be a liability to our organization or it could be going against certain laws or regulations. You know, one of the things that has already come up is GDPR and the right to be forgotten. People have a right to say, I don't want that information out there about me. Are we going to be able to go in to blockchain and delete that information? Privacy laws now often require a minimal retention. We used to say, or a maximum retention. I'm sorry, that's incorrect on my slide. We used to say retention's a minimum. You have to keep it at least as long. But now privacy laws are saying you really shouldn't have it any longer than you need it for the original purpose for which you collected that information or created that record. And we haven't been able to determine yet with blockchain. Are we going to be able to get rid of that when we need to? And then there's the whole issue of archival survivability. One of those issues is just doing appraisal. Blockchain presents a completely different scenario for doing appraisal than archivists are used to. Archivists are used to having a group of records and having a context behind it and a classification scheme and creating that in order to make it available to researchers. And now with blockchain, we're unable to separate records out without invalidating the rest of the chain.  The other issue with archival survivability is simply the long-term survivability of records on a blockchain. If they do need to be kept permanently, if they really are historical in nature or provide that long-term legal value, are we going to be able to access these into the future and for how long? We're going to need to have access to that encryption key and not lose it. I mean, we've heard stories on cryptocurrency where people have lost their key and they've lost their money, basically. We haven't looked into a transfer protocol that I'm aware of really. How are we going to get records from the blockchain to the archives? Are we going to send a node to the archives? Are we going to send all the nodes to the archives? Are we going to try to get it out of blockchain, which often at this point, there are a lot of proprietary blockchains, as with any other type of electronic record? And then, you know, we've talked about blockchain is decentralized. Is that a positive or negative when it comes to getting these records to the archives and making them available? And finally, of course, there's the cost. When we are talking about a chain that keeps growing that's never deleted, that is using multiple nodes from all over the place, that comes at a huge cost as far as preservation, as far as the power to keep it up and running. And I think that there are more and more studies being done on that aspect of blockchain. Now, I will say, because sometimes it does sound like I might be squarely in the con side of blockchain, that the more I do study it, the more there is some good that can come out of it. I was on a presentation recently and they were talking about identity management. Particularly, we were talking about identity management with, say, student records.  She needs her high school transcripts in order to prove that she's taken certain classes to get into college. And one of the things that I realized is that when it comes to archival preservation, if we can use blockchain for identity management, she doesn't necessarily need to have that copy of the transcript to send a copy of the actual transcript to a whole bunch of different places. That preserves the original and it means that there's less copies of that information about my daughter out there because all they really need to do is use that blockchain and those transactions to prove that she did, in fact, earn this particular degree in these areas. There are some legal challenges that come with this as well. Records-keeping laws are not keeping up with evolving technology. That's not just a blockchain issue. That's just an issue in general. And so we are trying to take modern technology such as blockchain and squeeze it into laws that were written a couple of decades ago and maybe only tweaked here and there. And it doesn't fit how we do business anymore. As I mentioned, defining the record and defining the pieces and the parts of a record is a challenge that hasn't been dealt with yet. And then what's considered destruction? Does it have to be a complete destruction or can we simply destroy the encryption key so that the record is unreadable? This is another thing that hasn't been tested in courts yet. Another consideration is are the nodes in different jurisdictions and could that present challenges to legal retention requirements, especially if the requirements are different in those different jurisdictions and who takes ownership? When it comes to litigation, records could be retained that hold an organization liable and litigation if we're not regularly deleting on blockchain because it's not that easy to do. We have to understand that some of that information could be harmful to us. So that's a consideration to take into account when you're thinking about what to put on blockchain is if we can't get rid of this, this is going to come back and hurt us in any way. And then as I mentioned, there are increased costs, but there are also increased costs and resources for e-discovery. And then finally, privacy law limits the distribution of information. So here we're talking about a system where the same information is repeated on nodes across the country, possibly across the world. And yet that seems to be in conflict with these privacy laws that want to limit the distribution of information. So there are some questions that as a records manager, you can pose in this process. First question, simple question, what's the retention period? And then following up with are there potential liabilities if we don't destroy it for retention? Usually we're coming up with a retention period because we should be getting rid of information when that expires. And then another question is, are there multiple record series represented in a single blockchain? Next, is there a benefit to recording a transaction? Or is that transaction part of another record or is it a standalone record? So is it just the transaction that's a record or are their records stored elsewhere that that transaction reflects? Also ask who needs access to the data? And are these persons going to change throughout the life cycle of the record? What tools are they going to need? And how are we going to pass those tools on from person to person? So what are the pros and cons of using blockchain for a particular project? Are there existing solutions that are already sufficient? I think we go back to one of Pat's first slides in thinking about that. And she had that nice little flowchart there. Finally, what are the costs and do the benefits of using blockchain justify the costs of it? A couple more questions, are there privacy and security concerns? People talk about the blockchain being wonderful for security, but at the same time that it's great for securing the information, is it in conflict with some privacy laws? And finally, will our organization have control over where the nodes are located? And that comes down to what are the laws in your jurisdiction or in the jurisdiction where these nodes could potentially be located? So those are just a few of the questions. And I think that the more we start to use blockchain and learn and understand it, we're going to come up with some more questions and we're going to be able to refine this list of questions. So thank you very much for that. And I'm going to turn it over to Amitabh Shrivasta. Great. Hi. Thank you, Perry, for the introduction. I've got a bit of feedback here. Hopefully that's better. All right. Yes. Hi. So my name is Amitabh Shrivasta. I was speaking a little bit about the risks that a new technology presents and, of course, new technology and its benefits versus the risks. So obviously, you've seen some of the benefits and certainly it's a lot of new ways of doing things using blockchain technology. So some of the risks that I'll be speaking about are actually discussed a little bit more in detail in the white paper that Pat was referring to, which is understanding blockchains roles and risks in trust assistance. So we're all familiar with the technology S-curve and obviously the new technology tries to solve a problem out there. But obviously, as with any new technology, you know, there's some hype around it. And of course, there's going to be improvements as the technology moves from the left-hand side to the right-hand side. And so therefore, any new technology requires a cost-benefit analysis. So as the technology moves through its improvement phases, you know, it'll have its early adopters. You'll go to your first-generation technology, second and so on and so forth. So during the improvement, there's obviously a lot of hype. You know, they're trying to sell solutions to problems that might not exist out there. And or they're trying to look for problems that may not exist. So it's important to really cut through the hype and understand the risks versus the benefits and determine if, in fact, there's a problem that needs to be solved. So the approach that we took is really to look at the risks from four different levels, so four risk assessment levels. Really moving from a high level, which is the, you know, the kind of strategic risk, should I use the blockchain? Then you get into your level two, which is a bit more detail, which is around design, then, of course, the implementation, and then more detail is really the operational risks. And so here, as you can see, the four risks are laid out in a kind of quadruple circle. You can see the little circle going from strategic value to operational. But one thing to look at really is the design risk because the design risks will really help define the scope of the potential solution, assuming you've decided to use the blockchain solution. So that's really important. And going back to some other speakers who spoke about, it's important to understand the implications of information risk management and the strategy for that risk management as you consider the design solution. So the next level, which is the design risk, we identified seven key risks, from governance all the way around to the project planning. And I'll sort of get into these a little bit more. But what's important to understand is that there are a lot of questions that both affect the technology that also affect the use of the technology more from processes. And of course, in how you're going to actually move forward in terms of implementing a project. So let's look at some of these design risks in a little bit more detail with respect to implementation risks. So what you have here are the seven risks. So we're at level two. So obviously the level one was the blockchain solution. So that's the strategic risk, whether or not to actually move forward. Then you catch the design risk. And you can see the design risks have a number of implementation risks underneath. So what we have here is really a risk breakdown structure or RBS or short. So if people are in project management, you will be kind of familiar with this. So what this lays out is a hierarchical structure of the risks in terms of how they can either percolate upwards or you can look at this from a high level and move downwards to a little bit more detail. So of course, this refers back to the four risk levels that we talked about a couple of slides back. So for example, you have governance, which is really around selecting the blockchain solution, providing some oversight and compliance, of course, records management. You can do some of the operational structures and how to manage and monitor the blockchain solution. You have to look at the organization's reputation. If the solution fails or other things happen, there is, of course, the technical architecture and the different options there. And we've talked a little bit about that as well. You do get into areas around legislation and regulation. Personal information, we talked about that. Data residency, which was kind of mentioned a little bit earlier. You also are looking to the IT operations, really from a data branch we talked about, how you defend the chain cryptography. So a number of areas from an IT perspective. Then, of course, you get into the project planning. So many of your regular project management activities, your business objectives, your business case. And we all know many times that these are not done properly. And sometimes in the brush to get a solution pushed out. So certainly that does require some project management oversight. So let's me walk through two examples. And then we can look at some of the level for operational risks. So let's maybe look at the governance. So that, of course, had four implementation risks. So here are some of the questions that what should be considered, you know, such as, do you have the electronic records for your mission critical digital assets? You know, do you have a large volume of additional content? So these are some of the questions one should ask. There could potentially be more questions, but this is a way to kind of get started. For example, the last bullet point under records management, we said, do you need to validate information from off-chain sources before hashing the information to the blockchain? So we've talked about some of these. You've got compliance questions, you've accessed, say, for the last bullet, do you need to establish providence of off-chain information before hashing the information to the blockchain? So you have some of those examples. If you look at, for example, business impact analysis, which is the fourth column, do you understand the specific recovery time objectives and recovery point objectives from a backup perspective? So anybody that does backups, you'll understand that. Big thing which gets missed many times is do you have buy-in from the board and senior management level committees for the actual business impact analysis report?  So those were some of the implementation risks. But so what we have here is kind of a risk assessment matrix. So obviously you've got your four implementation risks for governance. So, you know, you'd assign a priority to those risks, you'd probably assign somebody on the team to manage those risks. Plus certain audit activities such as objectives of audit, the audit controls, the type of audit, the audit classification and the frequency. So these are fairly common audit activities. This is not meant to be an audit framework by no stretch of the imagination, but certainly these are things that should be considered when you're looking at it from an audit perspective. Let's maybe take one more example. So what you see here are the operational risks for the blockchain architecture and some of these have been covered. So again, do you want to use permission versus permission less? So for example, as a last bullet, does the permissionless blockchain solution have passed to scale up as transaction volumes increase? You know, then again, you look at on-premise versus cloud-based, you look at blockchain as a service versus a proprietary blockchain. Consensus protocol is very critical. So if you look at the second bullet, do you want to do a proof of work or delegate proof of stake consensus algorithm? And of course that's important because one, may not be able to handle high volumes as well as the other. Mining architecture, again, they're questions to consider in terms of the ability to perhaps handle increasing volumes. So these are just some examples of questions that should be asked from an operational perspective meaning the level four risks. So again, the same type of questions should be asked. So in this case, we had five implementation risk areas. And so again, the risk priority, who's gonna manage the risk and again the types of audit activities that one should carry out. So the purpose of this matrix is again, to be able to map each of the implementation risks back up to the, sorry, operation risks, back up to the implementation, back to the design and be able to then obviously determine where the organization needs to focus its attention and its energy. So in conclusion, I think blockchain DLT does represent a lot of opportunities, but as with any technology, I think there are risks. And really, I think it's, I mean, the technologies do sometimes fail, but not because of technology itself, but I think because of not understanding the technology's risks and its benefits. So therefore, the initial hype has to be tempered with a proper risk benefits assessment before committing the organization to this direction. And that's it for me. Thank you so much for listening. I hear my contact details and I'll turn it over to Andrew. All right, thank you very much. At this time, we do have moments for questions here and there is a question here posed by Andrew. Looks like Andrew Kremtovsky, PI could be held on chain without contradicting privacy laws. He's wondering how is that possible? Questions located in the chat window. I'll jump in. I agree with Natasha and Andrew. Natasha, if I recall correctly, you're a lawyer in Russia, right? And so you're right. If there is specific law supporting the use of a blockchain that meets XYZ considerations for holding PII, then of course it could be legally done. To the best of my knowledge, we don't have law that necessarily supports that or at least that deals with the conflict between privacy law and, for example, we do have evidence law in Arizona about blockchain. But as far as I know, we don't have any laws that specifically provide that for that in North, or in Canada and the United States at this point. But if someone knows otherwise, I'd be more than happy to hear that. Excellent, thank you, Dara. Anyone else wanna jump in or do we have any other further questions? You're welcome. All right, Dr. Franks, you wanna put in some closing remarks here? If we can get you... I'd like to thank everyone for attending today. I really appreciate it.  Also make sure that you visit the 3D PDF Consortium link. Amitabh had mentioned the white paper that was published in January. And you will see much more information about the risks and the audits that Amitabh just pulled some sections out of that white paper to illustrate today. But there's much more information there as well. There is another question in the chat window from John. Oh, that's quite interesting. I had not thought about that. Seasonality issues, federal holidays, are infrastructures at risk. I imagine that would be the same as with any other technology that we're trying to protect from adverse influence or partners there. But does anybody have a comment on that? Pari, you work in government. What do you think? I mean, I think that it depends on the type of blockchain that is being used. If it is a public blockchain, I think that there could be more of a risk involved in it. If it's a private blockchain within the government, there might not be any more risks than any of the other systems that we have. Yeah, hi, this is Amitabh. Yeah, I'd agree with that. I mean, mostly these systems are designed to really run 24 by seven. Obviously, there are regular main test windows. So depending on the type of blockchain architecture one chooses, those things should be part of the architecture design. So holidays don't really affect the availability of that type of blockchain technology. Any other questions or just comments, things that you've been thinking about that we haven't touched on? Okay, then lots of miners could be using the same cloud. Cloud goes down, blockchain is in peril. Yes. Okay, I want to thank everyone. It's past our time here. I appreciate your attending. And if you have any questions for any of us, you see our email addresses on the screen there. Just grab them and get in touch with us. Thank you, everyone.


They're pretty common weapon systems. Both systems as well. I already had some with these. These, you won't really get anything, but maybe an audible pop. Again, if you just hear it and you notice it didn't shoot. Wasn't that great. But the next day... They're coming back to have to pay back. To pay back.


Okay, welcome back to the Splunk Conference, the Dot Conference 2013. This is SiliconANGLE, Wikibon's theCUBE, our flagship program. We go out to the advanced extract of SiliconANGLE Noise. We are live in Las Vegas. I'm John Furrier, the founder of SiliconANGLE. I'm joined by my co-host. I'm Dave Vellante of wikibon.org. Darren dances here. He's the UNIX technical lead at WorldPlay. WorldPlay is an online payment service provider. Darren, welcome to theCUBE. Thank you, welcome. So tell us a little bit more about WorldPlay. WorldPlay, sorry. Oh, WorldPlay, sorry, sorry about that. So WorldPlay is a payments company. We process a lot of transactions face to face in the UK. And we also are a worldwide online payments. They can be used for people who play games, right? Yeah. On-line gaming, right? Yeah, so online gaming, software purchases, micro-payments within applications. The platform is completely versatile and we have customers in the industry. So actually everyone's going gaga over, you know, square, brain tree was just sold to PayPal. I mean, payments is going to be ubiquitous, embedding them all across the network. And you bring up the notion of the, and the keynote they talk about the internet of things.  Yeah, that's a complex technical challenge. So how do you guys look at that? And what is, how does Splunk fit into all of this? So Splunk, initially when we put it into our organization, it was purely to do operational intelligence and problem solving. And then we're starting to break into the application space now to use it, to work out, for example, where our transactions are coming to run, to work out where our peaks and drops. And then going forward, we will expand that into customer-facing scenarios to help with our customer services and reduce the customer contact time. So you're giving a talk here at Splunk on securing Splunk for the enterprise. Yes.  Everyone's concerned about it. What does that look like? I mean, what are you going to be talking about on your talk? And what are some of the security challenges you see? Yeah, so what I'm going to be talking about is taking Splunk from the out-of-the-box solution to something which is more secure, which is better for the auditors for when the payments industry, we have to go through PCI, various other audit requirements. And it will basically be moving us from the out-of-the-box solution to something that auditors are happy with, that something our enterprise security teams are happy with, and something that is a more secure, better product. You know, Dave and I love talking about cloud mobile and social. DevOps is one of the hottest areas right now where you see people like Facebook throwing things around like just break stuff. And they're kind of changing their slogan now that they're getting bigger. But there's a lot of network challenges around protocols and security issues around perimeter security versus application security containers, virtualization is changing all that. Within that network environment there's a ton of data being instrumented. Is that mainly an application you guys do? Is that some area that's a concern or is it solid? What's your take on that? Massive amounts of data that we're generating because we actually split away from RBS two years ago and we just built our own data centers and we populated them. And now we're migrating all our applications and systems across. And the amount of data that we've gone from in the last 12 months that we're generating is just insane. We started just over 12 months ago with 500 meg a day on the free license. And we're currently capping the edge of 500 gig a day. That's a ton of data that's been thrown off. So take us back to when you decided to bring Splunk in. What was the driver? How did you justify it? How did it all happen? And what was it like beforehand? Paint a picture for us? Yeah, so I'd actually seen Splunk running and I'd followed it when it was a very early project. And we had a need at the time for an application logging engine so that we could start to do some analytics and we could start to find the problems that we knew were probably there but we couldn't see the symptoms of. So we brought it in initially on a small scale and then as we've built out, it's grown and grown and grown and we're starting to see real business value from the data that we're collecting and the analysis that we're doing on it. So it sounds like it came in under the radar, you probably didn't have to do a big business justification, right? There wasn't at the time. It's going for a lot more control now but at the time when it was small, it did slip in. Well, with that amount of data being indexed here. So, okay, so we'll talk about the business case a little bit so somebody sees the Splunk bill and they go, oh, what is this? Yeah. It's okay. And they go right to you and say, what are you spending all this money on? What are we getting? Yeah, so when we're rolling out new use cases, we've actually been collecting how long it's taking them to do it the old way and then we can map how long that's going to take doing it using Splunk and that helps us as our drivers for our business use cases because we can say, look, we put this in and it saved us X amount. It saved us this amount of time. It saved us reduce the number of contacts into the call center, for example. Talk about the old way. What is the old way? Well, the old way is logging on to each box individually and trawling through the log files using find, grep and all those good old Unix tools. Yeah, okay. And doing it. Yeah, basically, but you can't see everything in a single place. If you find an issue, you've got to go out and manually trawl across your entire state to find if that issue is occurring elsewhere. Whereas if you find an issue, you can actually then look in Splunk and say, well, is this issue elsewhere? Now, you're giving a presentation at the conference. Yes, I am, yes. Securing Splunk for the enterprise, how to keep your creditors away from your Splunk. Yes. So tell us about that. Yeah, so it's basically securing the out-of-the-box solution so that we can actually get it past auditors so that we can make auditors happy and comfortable that what we're putting in there is safe and secure and also role-based access control, which is really important. Because I've seen a lot of Splunk deployments where I've been chatting to people where they've created almost silos of Splunk, where the Windows guys have a silo of Splunk and the Linux guys have a silo and the network guys have a silo. I'm a great believer in making a highly available system where all the data is going into one place. We share the resource so that we get the benefit from the resiliency and the performance, but we need to control who has access to that data. And if you don't have need to access that data, you shouldn't have access to that data. Darin, talk about, obviously, securities. We talked about the security piece is important. You mentioned compliance, right? That's like the nightmare, everyone's nightmare scenario.  You don't want to look at it, but you have to at least stare at it. There's a huge compliance issue that comes down from like the CFO, the legal guys, but all the innovations coming up from the bottom up, right? So there's a collision happening, right? It does clash in the middle. It clashed in the middle. What have you learned and what are some of the issues that you found around compliance? How do you make it easier? What are some of the threshold issues? Any observations you share? We're really lucky that our current auditors at BCI have actually seen Splunk before and they're quite keen on it. Our previous auditors were a little bit scared and apprehensive. The main challenges that we've, because we are looking at security use cases and security guys tend to be a little bit paranoid about who can access what. And as long as we can demonstrate it, we found within our organization that if you can document it, demonstrate it, improve that you're not allowing people to access to the data that shouldn't have access, then we found it within our organization. It works very well. So two hours ago on the keynote, there was a comment on Twitter from one of someone tweeting, I have the quote, I'm going to get your comment on this. Quote, I've lost track of the number of times the security team has asked me to install Splunk 6. What do you think about that? I mean, is that similar vibe you're getting? Security teams are requesting it because of the ease of access to data? I think they will. I've only been exposed to Splunk 6 today from what I've seen so far. It looks really nice. Obviously there is going to be a small period of adjustment and we will start looking at moving to Splunk 6 in the near future, but we will wait for any more. The security teams in general are pretty keen on Splunk. Yeah, they like the benefits that it can offer and it moves away from your traditional SIM model. And I was chatting to someone a while ago within our organization and it was referred to a competitive product as it scales until it doesn't. Yeah, that's when you need the most, right? Everything that is based on a SQL backend only can go to a finite size.  People when they need it, the most is when this breaks, that scale. So is it because of the search and the indexing? We just had another alpha geek on earlier talking about the indexes and search. Is it the search or just ease of use? What's your take on why people like it? It's a combination of both, but it's from the infrastructure point of view to support the system, it's the scalability. I guess if the searches start to run slowly, you can put another piece of hardware at the problem and it's easy to put that piece of hardware in, you don't have to reinvent the wheel. From the usage point of view, we can have someone who is a relatively non-technical person, we can pre-prepare some searches for them. They don't have to have the full Google style search interface, they can just have type this in here and it doesn't even give them the log data back, it gives them something nice and pretty that they can use to do their job which makes their lives easier. So Darren, you mentioned that you've been following, you were following Splunk early on, you followed the project early, you got in early. There wasn't probably a lot back then, but now you're seeing everywhere we go, John and I here, oh yeah, Splunk, we do that too and we can do that, we've got the Splunk killer, there's open source alternatives coming out, so why Splunk, what else did you look at? Maybe there wasn't anything there, but I'm sure as any technologist you're constantly looking at things, why Splunk? We looked at some of the open source alternatives and yes, they're free, but you have to make, you've got three or four different products to give you the same as Splunk. So Elasticsearch, Logstash would be another one, and some startups lately, but yeah, and the open source alternatives, you start to put the tools together and you've then got to support three or four different tools rather than one where you can go to one person and you've got one throat to choke. It's not a solution. It's not a solution, it's a bunch of products. And the support experience is not there, but over time, it could be. It will be, yeah. Now, so what would your advice be to Splunk with regard to open source? To keep an eye on it, to see what features that's offering and if it is bringing good stuff to the table. Embrace it. Yeah, embrace it, don't resist change.  How about other practitioners that may not be as familiar with Splunk, may be hearing about it for the first time. What's your advice in terms of bringing it into the organization? You said you started small and then grew any other landmines that you might want to try to avoid? Yeah, we still have people within our organization that still see Splunk as just a log archiving engine where traditionally we've taken data in, we've kept it for our audit retention periods and then it's been thrown in the bin. And there's so much information that is in that, in that data that we can use to enhance the experience for our customers, increase stability, reduce downtime. It's all there, we just need to embrace it and mine it and make use of it. What about the cloud platform? Were you using Storm or no? No, we're not using Storm. Okay, so what about cloud in general? Is that something that you guys, I mean, we, from a security point of view, we're a little bit hesitant about it. Just a little bit? We do have parts of our organization which are using cloud services while we get ourselves up to standalone strength. And we will be bringing those into our data centers if appropriate. Okay, so maybe those are sort of less risky applications, things that you're not as concerned about, but what about an organization that, let's say a commercial organization, maybe they're smaller, they don't have the resources to manage their own environment that's going to the cloud. As somebody who follows this world, understands the security, the threats, the risks, and some of the privacy issues, what kind of advice would you give to those people that are actually looking to get into the cloud specifically as it relates to security? If you can manage the risk and if the risk is acceptable to your organization, then the cloud is a great way to go. And if the risk is not acceptable, then you are unfortunately bound and have to invest in the infrastructure yourself. Do you agree or disagree with this statement that for the vast majority of organizations, a cloud service provider's security is going to be better than the organization's? True or false in your view? I disagree. No way, right? Okay, so talk about why. Cloud service providers are all about enabling people to get stuff done quickly. And part of that enabling means not restricting stuff. For example, you go to many virtual server providers and you will get a GUI. You will get loads of stuff, which is inherently insecure. Everything we do is stripped down. We take away anything that is not required to reduce the scope of attack and the surface of attack. So how do you balance that natural tension between flexibility and agility, making things easier to do and the need to secure your organization? I mean, they're almost completely counter poised. They are. So at one point you end up with someone's got to make a decision whether you go for a solution that is really secure but costs a lot more to support. And because you've got, say, the increased management overheads, because you've got to do more things, you've got to have more skilled engineers, you've got, if you're putting a new application live, you've got more relaxation that you have to do on your security measures to allow that application to function. And there is a balance to be had there with your developers, which just have a go heroes and they want it to work. It works absolutely fine in development and they can't work out why it doesn't work in a production area. Have a go heroes, I like that. Now, so how is that decision made? Specifically that balance between risk and value. Within our organization, we actually have people that are sat there managing the risk and working out which way is the appropriate solution to go? Should we be relaxing security measures or should we be keeping high security for that particular application? Right, because as a practitioner, you don't want to own that decision, but you obviously want to have input. Yeah, we provide input and we pass along our concerns and why we would want to do something in a certain way. And then we pass that up the chain of commands and they pass back down which direction they would like us to take. So what's on Splunk's to-do list? So, talk to management, what would make your life easier? And with regards to features or? Yeah, either features or policies or business practices or new products that you think they should introduce. Yeah, I think there is room for growth within Splunk. I think they could do some brilliant stuff going forward. And I think with Splunk 6 and where they've got rid of the advanced XML interface and the introduction of the pivot tables and the new engine to make everything go a lot quicker and easier, it reduces the need to have to train people on the search interface as much, which means you've got a quicker time to delivery for your lower skilled staff. We've been talking about that as sort of the holy grail, particularly in big data. A lot of initiatives, I'll say, whether it's the old decision support, the business intelligence crowd, the data warehousing crowd, there's been a lot of promises put forth that we're going to put tools in the hands of business users. Are we there? I really think we're at the point in our industry where that is becoming a reality. We're getting there. There are products such as Splunk which are enabling the business users to start to take control of the data that is sat in the IT infrastructure. Some of the competitive products that I've seen are very much focused towards security, for example. They're very much focused towards fixing IT issues. We haven't quite got there with all the products on allowing the business users to embrace their own destiny. Excellent. All right, Darren, thanks very much for coming on theCUBE and sharing the world-pay story. Really appreciate it. Thank you very much. We'll be right back. This is SiliconANGLE in Mukibon's exclusive coverage of Splunk.conference 2013. I'm John Furrier with SiliconANGLE, showing Dave Vellante. We'll be right back after this break with more exclusive coverage. Day one of two days of live streaming here in Las Vegas. We'll be right back.


Hi, my name is Olajumoke Oke. I work at International Buries in the Revenue Management Function. I just completed a course with Dibran Consulting with trainer Adewali Yusuf. The whole experience was very informative, was very educated, I learnt a lot, a whole lot. Even though I use the tools that they taught us every day, I've come to realise that I really do not know much. I've gotten a lot of knowledge. The trainers were very patient, they were very educated. They took time to explain to us, and I'm happy that I took this course, and I hope that my work gets out from now on.