Hello everybody, this is Shawn Daugherty, from the University Alliance. I'll be your host this evening. I would like to welcome everybody to the Developing Secure Applications Webinar. We appreciate you taking the time to visit us with this evening, and we got a great presentation for you.
I would like to go ahead and introduce the panel members for this evenings presentation. We have Dr. Liam Mayron. Dr. Mayron is the degree chair for the Florida Institute of Technology Harris Institute for Assured Information. And with that I'm going to go ahead and turn it over to Dr. Mayron. A quick note, that if you have any questions, you can go ahead and ask those questions throughout the presentation utilizing your chat function. So, if you look up at the top of your screen you will see a little green bar. If you mouse over that green bar there is a chat box up there. If you'll click on that chat box then that chat box should appear on your screen and that's where you would go to type in questions. Again, feel free to go ahead and type in questions throughout the presentation, and we will have a Q&A session at the end of the presentation where we can get those questions answered. And with that, I'm going to go ahead and turn it over to Dr. Mayron.
Good evening everyone, and thanks for joining us. Today I'm going to talk about developing secure applications. So we'll talk about why applications are insecure and where those insecurity's and vulnerabilities originate. What are some of the top or most common vulnerabilities in an applications, with a bias more towards applications. And then what are some of the things that we can do about it? So, one of the reasons applications are so insecure today, and we keep on finding more and more vulnerabilities is a change to how we use and deploy them. In the past network security was enough. Corporations could only allow the simple services like email to go onto broader internet and block everything else. And that worked pretty well for a time.
Today, however, what we have is, we have the web, which is a necessity in most enterprises. And as a result, port 80 is, which is the port that we browse the web over, is open and everything uses it. So, of course, we can throw FTP over that port even though we’ll block those ports explicitly. Another problem is, even if only the web is allowed it's still connected to the back end to the application server at the database leaving the recipe and enterprise vulnerable. One example of this is power plants and there's a big interest in the state of security today. And power plants historically for many decades have relied on physical security. And that's worked very well. Once inside there most of the passwords are set to defaults or put right next to the station they need to be used at because time in getting in is more important than denying somebody from getting from accessing the workstation because there's a good physical security mechanism in place, only allowing people that are authorized to go into sensitive areas of the power plant. However today, because there's a desire to do work more efficiently and work from home and remotely, and maybe use an app to monitor and track certain systems, this is dramatically increased the attack surface.
So let's go forward and talk a bit about how applications are vulnerable. And there's a lot of lists I've discussed and a lot of articles I've discussed so, what are some of the top vulnerabilities. For this talk I'm going to look at the top ten from OWASP, which is the Open Web Application Security Project.
So, the top one is injection. And, when we talk about injection, usually we're talking about SQL injection. This happens when there's untrusted data that's sent as part of another command, and eventually, executed. The consequences for this are severe. At the low end there could be data loss or exposure of data that shouldn't be exposed. But consequences can lead all the way up to data corruption and even a loss of all data in a system.
Oh, one example we use for this, this is a popular comic from a site called XKCD. We use these a lot in, in our classes and in this case the lady named her son Robert apostrophe parethesis semicolon drop table students. And this is a SQL injection attack. If your, if your database is or if you're not sanitizing your inputs, if you're not watching what's being executed, if someone enters that as their name, it may end up deleting all of the students. So. That's injection.
The next vulnerability, and this effects web applications, is cross-site scripting sometimes called XSS. What cross-site scripting is when user supplied data not properly validated and then returned back to the user. An example of this could be a search box. If you enter search term and then click search, sometimes the resulting page says you searched for, and then it prints what you searched for. Or maybe you have a username when you sign into a site and then it displays your username at the top of the site. Well this is a nice feature if all the users entering is legitimate text. However, if the users enter some malicious javascript it allows an attacker to execute arbitrary javascript within the security context of the host site, which shouldn't be allowed.
And the consequences of this are also quite damaging. An attacker can take over user sessions by gaining access to the session tokens, the attacker can force a redirect to malicious sites or even change web site content. Maybe replace blocks of the web site like the log in box or something that sends a user's credentials to a malicious site. And this is actually the most common web application security flaw.
Another top vulnerability is broken authentication and session management. There are many poor implementations of authentication session management and what we mean is signing into a site, signing out, or updating password, tasks like that. When these aren't implemented correctly lots of vulnerabilities abound. Attackers can use this to take over passwords, learn user ID's, execute group force attacks to gain access. Gain other user session tokens, if you have another user's session token you can actually impersonate that user, potentially, and also exiltrate other information about users. There are some good design patterns for implementing solid authentication schemes and good session management, so if you're tasked with developing this, see if that's available. Don't try to reinvent the wheel. Common flaws occur when, when signing out of the session is not properly destroyed or maybe just appears to be destroyed and the client is still persistent the server, leaving open for maybe a replay attack. Improper use of handling of passwords, not implementing a session time out correctly. Broken implementations of remember me feature, which is very convenient, because users don't need to sign in. But it needs to be implemented in, in a way that lets them discontinue it. Poor choices of secret questions. So secret questions are a convenient way of recovering a password, and banks and many other sites use them. There's been a trend to simplify those questions and the reason is smartphones. People don't like typing long strings on smartphones, instead they prefer to select from the list, and this can lead to a lot of security complications if the secret questions are too simple. So some of them can be guessed by brute force. I've seen questions as bad as, what's your favorite color? Well, with a few guesses, even if you know nothing about the user, you could probably guess the, the color they, they put in. A better approach is to allow the user to choose some good questions.
Another flaw is insecure direct object reference. And this happens when we expose some of the internal workings of the application to end user that shouldn't be exposed. So maybe we are showing them internal directory structure of the site or even worse, we're exposing the database schema. Which could share information that allows an attacker to maybe execute a SQL injection attack.
Cross-site request forgery is another serious vulnerability. This is a violation of the trust that exists between a website and the users browser. And, what happens in this case is the user will sign into a site, say a banking site, and then while they're still signed in, open another tab, or a few other tabs, and do other browsing. But what happens here is, if the user subsequently gets redirected to a malicious site. That site can pretend to be the user and execute requests at that bank site, or whichever other site they're signed in. The server has no way to know if it's the user creating the request, or if it's actually a malicious site. That's creating a request, some counter measures include adding random tokens within pages, or requiring re-authentication before sensitive transactions.
Security misconfigurations is a big challenge. What this fundamentally comes down to is, that many applications are not shipped with secure defaults. And that should never be the case. The user should never be forced into an insecure state, even for a little while. Application should ship in a secured place. And then allow the end user of the option to lower the securities that suits their need. Of course, many of these systems are very complex, and there's a lot of opportunity for misconfiguration or testing that doesn't catch misconfiguration. Another alternative here is using an automated scanner to help detect some common misconfigurations.
Failure to restrict URL access is one of the simpler ones to, to describe. What we mean here is sometimes there'll be resources behind the password protected area. Like an admin page. Maybe there are some PDFs or other documents that should only be restricted to a certain audience that has that password. Sometimes the page that links to these resources will be protected, but the actual resources will be not. And they can be accessed directly without having to authenticate.
Unvalidated data redirects and forwards. Redirects are very common on the web and in many cases the user doesn't actually know where they're being forwarded, and it could be a malicious site. One thing that's making this worse is the problems of URL shorteners, and or in many cases you can go to the site and put in the URL and see where, you'll actually end up before you go there. Most users just click ahead without actually knowing where they're really going to end up.
Improper use of crypt, cryptography is another flaw. There are many good cryptographic algorithms out there, and if they're used correctly, they can be very effective. Unfortunately, they're not always used correctly. One common flaw is not generating keys in a random way. Some systems have been hacked because it's been found they have actually hard-coded seeds for their key generators, which makes it very easy to predict which key will be used to encrypt the data, or even having static keys that don't change. Another flaw is unsalted hashes. Hashes is a way that we can protect passwords and other data that, with a one-way transformation, a salt is a token that's added when that hash is generated that slows down brute force attacks.
And the last vulnerability is insufficient transport layer protection. So you've probably seen a pop-up like this many times. It looks different in different browsers. It's referring to an expired security certificate. And if you're like me, you probably click, click through. Of course, this is the security vulnerability. The site could have been compromised. At the very least, it's not configured correctly and the certificate needs to be, updated.
So things probably sound pretty bad at this point. There's a lot of vulnerabilities and these are just a few of the top ones. Let's however there is good news. Some good practices that we can use to have overall more secure and more robust application. And these principles are also provided by OWASP.
So first one is defense in depth. And of course we have it in the network, in the digital systems but, in physical systems as well, defense in depth is a pillar, think of an airport there's many layers of, of security, there's monitoring as vehicles approach the airport, there's security at the checkpoint, where you actually have to go through and get scanned. There's another check at the gate, to make sure that you have a ticket to, to board the flight, and other gates in between, or other checks in, in between, if you have checked luggage, and so on. In digital systems, we have a network layer, host layer, an application layer, and even a layer to protect the data. The goal is that even if one of these layers fails, there'll be one below it that cannot fail in the same way, and will catch any transgressions.
Another good practice is to have a positive security model. And one way to think of this is a system that denies everything by default, and only allows what's necessary to go and so, surfaces or addresses are exclusively authorized on the system should be allowed to, to function. Now this can't be used all the time and sometimes you don't know, for example, which web addresses you'll have to access on a certain system. In this case you can use the, a more relaxed method, blacklisting. In which case, you allow everything by default, but have a list of services or addresses that you deny.
Another important thing to do is to fail securely. So applications, of course, do fail but what we want is that, when they crash or have bugs that they don't leave, that they're not left in an unsecure state. So good practice is always to have the path that would disallow the action be the same one that should happen if there's an exception.
Another good principle is to run with the least amount of privileges necessary. User accounts should only have what's necessary to accomplish their task and nothing more. And this includes user rights, but also CPU resources, memory, network access, file system resources and anything else that may be on the system. One attack actually took advantage of the flaw was a feature for HTML 5, that allows storage on the hard disk and filled up hard disks. So you want to make sure that only the list amount of privileges are granted to a particular application.
You should avoid security by obscurity. What security by obscurity is, is when you try to make a system more secure by maybe hiding some, some key path or, or feature. And because or maybe even making the code very, very difficult to follow. This is a very bad practice, because the security of the system hinges on secrecy, and once the secrecy is exposed, you're left very unsecure. A better approach is to have the system secured with methods that are well-established and public. If you saw the most recent James Bond movie, Skyfall, it had a bit of a cybersecurity theme. But, there were a few points I cringed. And one of them, was when they were showing the bad guy's encrypted algorithm on this fancy display and they said, oh, he's using security by obscurity. We can't track him. I thought, well. Now that's a really bad thing. Security by obscurity is generally a bad practice.
On the other hand, a good practice is to keep security simple. Avoid a complex implementation when there's a simpler one available. Another benefit here is that the time required to test the system and deploy the system is reduced as well.
It's important to have a facility to detect intrusions, and what this means is not only having a logging but having a way to actually monitor the logs. It's no good if you log a system but then you have too much data to actually monitor and respond to. Also logging has to be done, in a secure way. You have to be careful not to log, sensitive details like, user passwords and so on, if it's not really necessary.
The next two principles are very similar. One is don't trust infrastructure for security. One hardware can change over time and some functions may not be present. And the next one which is related is don't trust software services or external systems or even external libraries. Make sure you have the functions that you need. Also if you're expecting a certain environment keep in mind that external libraries and services may be upgraded or changed over time and this may affect the security of the system.
And finally, we touched on this a bit earlier, but have secure defaults. Your application should not be insecure out of the box. It should be secure and give the user a choice to downgrade the privileges if they choose to.
Well, thank you very much. And I'll pass it over to, to Shawn.
Thank you, Dr. Mayron. So I'm going to go ahead and talk a little bit about the university and what it has to offer. So Florida Tech is a traditional brick and mortar university. It's been around for more than 55 years. It's non-profit and private. And then has displays academic excellence. And now, of course, the you have the online convenience piece of it because programs are offered 100% online. A little bit about the university, it's ranked a tier one best national university by U.S. New and World Report. And that's, that's something that's very prestigious. That's something that we're very proud of. It's ranked also among the best by Barron's in the Best Buy category. So the education is, is a great value. And I think that one of the things that I'm always, that I'm talking about is the value of the education. When you receive this education, the knowledge that is received in academic excellence and, you know, when you sit before an employer, what that's going to mean to that employer. And one of the other statistics that I'm going to point out here that we're very proud of is that PayScale.com has ranked bachelor degree holders with the highest starting and mid-career salaries of any private research university in Florida. And that's, that's very prestigious.
Talking a little bit about faculty. One of the things we have with the Master of Science in Information Assurance and Cybersecurity. And the Master of Science in Information Technology with a Specialization Cybersecurity is dedicated faculty. These faculty are very distinguished within their field. And most of them are practicing experts. And so, we're very proud of the faculty that teach in the program. The university is regionally accredited, which is really the highest level of accreditation recognized by the Department of Education and we also have athletics, the Panthers, which is the university mascot. We participate in Division two sports and we recently started a football team, in 2013, in fact the first game is on September 7th. Against Stetson University. We're very proud of our University and everything that it represents.
In the course, the next points that I'd like to point out the online convenience piece of it. So it's the marrying of the academic excellence and the online convenience. When you really truly go mobile. When we are offering this degree it's synchronous and asynchronous. Meaning that you can do that when you have time. You know, we understand that working adults have lives and busy schedules and commitments and it's very important that this program provides the opportunity to allow you to do your studies when it's best for you to do your studies. And so there are a lot of many different features such as streaming videos lectures, CD ROM, MP3, MP4, group study, which is a great feature, where you can actually have, very similar to a live classroom with the availability of whiteboard being able to share presentations, Word documents as well as, verbally be able to speak with the faculty member and your other classmate. And we also have social and mobile classroom functionality. So it very much feels like a learning community. And again, this is all available 24/7 through the dynamic learning management system that we have and the classroom that we have. And this is all provided at a very competitive tuition rate. Students are able to, again, have access to a world class education. And, and do that with a very competitive rate.
With that, I'm going to go ahead, and turn it back over to Dr. Mayron to talk a little bit about the Cybersecurity focused programs.
Thanks Shawn, well at Florida Tech we have two graduate level Cybersecurity Programs. One is the Master of Science in Information Technology with a specialization track in Cybersecurity, and the other is the Master of Science in Information Assurance and Cybersecurity. So the first one the MSIT. This is a program with its roots in the college of business. So the curriculum is primarily focused on IT on management of resources within Enterprises. But we have a track, which is well, one of the security courses is a course for the degree and then a three course specialization, where you'll learn about some of the IT related aspects of host based security, network security, and also enterprise security. The MS in Information Assurance and Cybersecurity or the MSIAC, this is offered from the College of Engineering, and this is a technical degree. We created this with partnership from Harris Corporation and with our research faculty here at, at Florida Tech.
If your background includes programming or you have a prior degree in Computer Science, Computer Engineering, Software Engineering, or a related field. This may be an interest point, an interesting way to move forward and look at some, both the low level and high level technical aspects of cybersecurity.
And with that I think we're ready to take some questions.
Yeah, thank you, Dr. Mayron. We had a couple questions come up during the presentation, and I'll just start reading them off, and either you or Shawn can answer them as you see fit. The first one is:
Can you explain the difference more between MSIT and MSIA? I know you kind of touch on it, at the end there, but in the real world, when getting a job, which degree kind of puts you in place for which type of career?
Sure, that's a really good question. If your goal is to go into IT, into management if your background is not in science or engineering, MSIT's probably a more appropriate program for you, because in addition to the cybersecurity courses which are at a less technical, more enterprise oriented level there's courses such as project management. However, if you have a technical background, and want to continue along that current path then, you should look at the, MSIAC degree.
Yeah, I, I believe one of your colleagues once explained it to me. Like, you want to build the tools or use the tools? That's the difference between MSIA. Where you will build the tools and MSIT where you would use the tools.
Yeah, that's a good way to put it, much more succinct than, than I put it, I like that.
Alright the next one from Dan is:
How much coding program do I need to enter either program? And does it count if I did a little bit of it during work?
Well, we review each application for the MSIT. You do not need a coding background. If you're interested in the MSIAC we do look for a few semesters of coding experience. However, we'll consider some applications that haven't had the course work because there are people that have that incredible coding experience, some really interesting environments that we want to include in the program as well.
How long would my degree take me to complete if I was working full-time?
Well, these course they're offered in eight week modules and generally, students take one at a time. I believe both degrees are 11 courses and we have 6 eight week terms a year. So as a result, if you go straight through you should complete it and eight weeks short of two years, I got twenty two months.
And another one back on experience:
If I don't have a lot of coding experience is there anything I can do between now and the time I apply to better position myself for class?
Sure there is definitely a few things you could do and then if you get in touch with me directly at lmayron@fit.edu or through our website and University Alliance will definitely direct you to some resources. We also have a class that we offer in some cases for the MSIAC where we have, I mean, just interested applicants and they haven't coded in a decade or more. And this course kind of gets you up to speed and refreshes all of the, all of the programming concepts that you'll need throughout the rest of the degree.
What appears to be our last one is, if I were interested int he programs what would my next step be?
Shawn that might be a good one for you.
Sure. If you are interested in hearing more about the degree and getting more information you can contact us at the University Alliance. You can go to the website and there are, there's a lot of information about the programs as well as, there are forms that you can fill out to request more information and get in touch with one of our enrollment advisers. And I believe that we have, at the end of the presentation, some links as well as a phone number that you can use to get in touch with us to, again, inquire more about the program. The one thing that I also would like to point out is that we do also have a certificate and that is available for the MSIA and so it's a, a forcredit graduate certificate in Information Assurance and Cybersecurity. And that program is, is four courses and can be obtained, attained in as little as eight months. And it's for credit so the program can be utilized as twelve credit hours and applied to a full degree if you interested in getting, going for the full degree after that. So that's one of the things I wanted to go ahead and mention.
There doesn't appear to be any other questions. So, I think at this time we might be done, unless anybody wants to type anything in last minute.
Does anyone take more than one course at a time, to finish earlier than 22 months? And if so, is that difficult or recommended?
Uh, we don't recommend it and I think when, first things is, is to get to the courses and see how it is, but no I actually don't know anyone that's ever done it. These courses are, are taught on campus in, in sixteen weeks in the full semester so, to have them in eight weeks is twice the pace and so we, we only strongly recommend they take one at a time.
You're very welcome Mike and with that I, I think we are done. If anybody types any last minute questions we will have someone contact you tomorrow as follow up with a copy of this presentation and to answer any other questions that you might have.
So thank you for joining us this evening.
Thank you.
