video

Explanation of Cybersecurity Hashing and Collisions

August 29, 2021 by Christian Espinosa

This blog post is a transcript of Christian Espinosa’s explanation of cybersecurity hashing and collisions and covers the following:

What is hashing?
What is a hashing collision?
What are hashing birthday attacks?
Includes a demonstration of a 3-way MD5 collision

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need cybersecurity help? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete Cybersecurity Hashing and Collisions Explanation Video Transcript

How’s it going? This is Christian Espinosa with Alpine Security. Today’s topic is on hashing and collisions. First off, what is hashing? A lot of people think hashing is encryption, but hashing is really not encryption. It is a mathematical function, but when you do encryption you typically need a key to decrypt something. With hashing, there’s no key involved. Hashing is really a one-way function. What that means is if we take some data and cram it through a hashing algorithm, out spits what’s called a message digest. The message digest is a fixed linked. The data we cram through the algorithm can be a variable linked. We can cram one byte or one terabyte through let’s say an MD5 hash algorithm and out spits a 128 bit message digest, regardless of the size of data we put through it. It’s called a one-way function because you can’t take the message digest value and go backwards through the hash algorithm and reproduce the data that was used to create the message digest. It doesn’t work that way. It’s only one way.

Hashing is used for integrity and to store passwords. Passwords should never be stored in cleartext. They should be stored in a hashed format or message digest. That way if someone types in a password on the password system, the password is hashed. If the hash value matches what’s stored, you know what the password is. There’s a little bit more to it than that, but that’s basically the concept.

Hashing is also used for integrity because if I take some data and run it through the hash algorithm, I get a message digest. If the data changes that all and I run it through the hash algorithm, I should get a different message digest, which tells me that the data has changed. If the data is the same, I’ve run it through the hash algorithm, I get the same message digest, I know I have integrity and the data has not been altered. One of the primary uses of hashing is for integrity and another use is for passwords.

There’s a lot of discussion about collisions and I’m going to do a demonstration here. Collisions are when you have two different inputs, you take it through the hash algorithm, and both different inputs produce the same message digest. That’s called a collision. Two different things produce the same thing, collision. Technically, that should not happen with hashing. If it does happen, it kind of breaks the concept of hashing because now we can have two different things that produce the same message digest. If we think this thing here hasn’t been altered, but it has been altered, and if we look at hashing to prove that it hasn’t been altered, we may have a false sense of integrity because the two different things can produce the same output or the same message digest, which is the collision.

I’ll give an example of collision. MD5 is a common hash algorithm that’s been broken, as they like to say, and there are examples of collisions with MD5s. MD5 uses 128 bits. SHA1 is another type of hash algorithm that uses 160 bits, and there’s quite a few other ones. SHA512 uses 512 bids. But basically the larger the message digest, the more bits, the less likely of a collision, based on simple math at math. With MD5, there’s 128 bits. There’s a lot of discussion about collisions, but the bottom line is collisions are highly unlikely, even with MD5. It’s very unlikely somebody can intelligently alter some bit of data and generate the same message digest as some other signed piece of software, for instance.

Let’s just look at the math for this. I’m going to bring up a calculator in scientific mode and with 128 bits, that’s 2 to the 128th power, because we have a zero or one, which the 2, 128 bits. Those are the number of combinations with 128 bits. Let’s just look at that. So 2 to the 128, equals 3.4 whatever. Basically, that’s a really large number, so the probability of creating a collision is very small. It is possible though. This probability is going to be smaller with SHA512, there’s more bits.

The example that this one guy has figured out with MD5, is he’s had three images that produce the same message digest. What this guy did, if you actually look at the images in a hex editor, is he basically took one base image, which had a specific message digest, then he took another image and altered a bit at a time in the header of the image and kept running it through the hash algorithm until it basically produced the same messages digested. Then he stopped altering the bits, and the images look different because we’re not looking at the metadata, we’re just looking at the actual image data, visually. Then he did it again with a third image. This is the proof that there are collisions with MD5.

et’s look at this here. We’re going to use this tool called HashCalc to do the calculation. HashCalc is one of my favorite hashing calculators. If we just searched for White, Black and Brown MD5, we should find what this guy did. Three-way MD5 collision, Nat McHugh’s the dude’s name. Basically, we have these three pictures, Jack Black, James Brown, Barry White, I believe. I’m going to save each of these. I’m going to save this one as Jack Black. This one is James Brown. This one is Barry White. Then we’ll run these three through the hash calculator. And you can see, I’ll go ahead and open the images. If we look at the images, this one is obviously different than this one, and different than this one right here. The three images are different. The three data sets are different, but they produce the same MD5 message digest.

Let’s check this out. Here’s HashCalc. I’ll put the link to HashCalc in the video. With HashCalc you can just drag and drop the image. Here is Black, I’m going to drag it over here. Before I do that, I’ve got MD5 selected and I also have SHA1 selected. We’ll do the message digest for both of those algorithms. So there’s Black, here’s the message digest. I’ll go ahead and copy this. I’ll put this here in our notepad. Black equals this. That’s the MD5, and the SHA1 though, is this, for Black. That’s the SHA1. Let’s try White. White equals… Let’s take White and we’re going to drag the White image to HashCalc. So the MD5 for White is this. That’s MD5. The SHA1 is this. And with Brown, let’s try that one. You kind of know where this is all headed, right? With Brown, we expect the MD5 to be the same. We’ll drag it over here, I’ll go ahead and copy that. Brown MD5, it looks like it’s the same. The SHA1 should be different.

All right. With Jack Black, MD5 right here, Barry White right here, and James Brown, same MD5, three different inputs, that’s a collision. You notice the SHA1 is different for all three though. It is extremely, extremely unlikely you can create a collision that works with all hash algorithms. I’ve never seen that done. I doubt anyone can do it. If you want to check for collisions, just simply use two different hash algorithms.

I was going to talk about the birthday attack. That’s the other thing I have in the list here. The birthday attack is simply this mathematical probability. They like to talk about it a lot in certifications like the CISPD and Security Plus. All it really is, is probability. The whole idea is if given enough sample size and with birthday is we mean, if we have more than 23 people in a room, or 23 or more, the likelihood of two people sharing the same birthday, not the same birth year, but the same birthday, is over 50%. That’s because we’re not comparing everyone to you. We’re compared to everyone to each other. It’s just simple probability.

They like to use this concept to say how easy it is to create a collision with hashing. It’s not really that easy. It might be relatively easy for MD%, but still like the Jack Black, James Brown and Barry White, those are simply images where the header or metadata of the image was altered. To be able to intelligently alter something, to make a malicious file look like a signed piece of software, in my opinion, it’s not going to happen, regardless of what people say about this birthday attack and how easy this is, it’s really not that simple.

That’s all I wanted to talk about today, what hashing is, one-way function. You can’t take the message digest and go backwards and recreate the piece of data used to generate the message digest. We talked about collisions. There are collisions with MD5. It’s been broken per se, so has SHA1. But if you use two different hash algorithms, even if you have a collision on one, you could easily tell the data is different. We went over an actual example with collisions. We also went over HashCalc. I’ll put the link to HashCalc as well as a link to Nat McHugh’s site where you can download the Barry White, Jack Black and James Brown images and test out the collisions yourself.

If you have any questions or comments, you can lead them beneath the video. Please subscribe to our channel. Click on the little bell so you get notified when we have new videos. Thanks for watching. Have a great one.

Explanation of the Cybersecurity CIA Triad

August 29, 2021 by Christian Espinosa

This blog post is a transcript of Christian Espinosa’s explanation of the Cybersecurity CIA Triad, and the opposite – DAD, and covers the following:

CIA = Confidentiality, Integrity, and Availability
Technologies used for each:
- Confidentiality = Encryption
- Integrity = Hashing
- Availability = Load-Balancers, Hot Sites
DAD = Disclosure, Alteration, and Destruction/Denial

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need cybersecurity help? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete Cybersecurity CIA Triad Explanation Video Transcript

Hey everybody. This is Christian Espinosa with Alpine Security. Today’s topic is on CIA, not the Central Intelligence Agency, but confidentiality, integrity and availability. These three things are what we try to achieve with cybersecurity.

With confidentiality, we’re trying to prevent unauthorized disclosure of our data. The technology we typically use with confidentiality is encryption. So I want to encrypt my data in transit and at rest. So if I’m sending some data to Amazon, such as my credit card number, and somebody intercepts it, they can’t read the data unless they have the encryption key. It’s kept secret. If somebody steals my hard drive and I’ve encrypted my hard drive, my data is not disclosed to them unless they can decrypt the hard drive. So confidentiality, the technology we use is encryption.

Integrity is to make sure our data is not altered, either intentionally or unintentionally. That technology we use for integrity is hashing. So if we use a hashing algorithm, such as MD5, SHA1, SHA512, if we use any of those, we take the data, we run it through this hash algorithm, it spits out what’s called the message digest, that if I send you the data, you run the data you received from me through the same hash algorithm, you get a message digest. If your message digest matches, sorry, my message digest, then the data has not been altered. So that’s hashing and that’s used to prevent alteration or to see if data has been altered.

The a stands for availability. If the data is not available, it’s kind of useless. With availability, we typically use things like load balancers, backup sites, hot sites, mirrored sites, et cetera for availability.

The opposite of CIA, is DAD. That stands for disclosure, alteration and destruction. With disclosure, it’s the opposite of confidentiality. So if your data is disclose to me or to a hacker, you have no longer achieved the objective of confidentiality. With the A, alteration, if your data is supposed to have integrity, but I’m able to alter it. Let’s say I go to your shopping cart and I can change the price of your thousand dollar item to $1 then I’ve altered your data and that is not achieving integrity. The other D stands for destruction or denial of service. So if I’m able to destroy your system, like your server, or do it the of service on your server, then I have removed the availability of your system to your users. So that’s DAD, disclosure, alteration and destruction.

I hope you enjoyed this. Quick tutorial on CIA and DAD. If you have any questions or comments leave them beneath the video. Please subscribe to our channel. Thanks. I’ll talk to you later.

Black Box Penetration Testing Explained

August 29, 2021 by Christian Espinosa

This blog post is a transcript of Christian Espinosa’s explanation of Black Box Penetration Testing, which covers the following:

Differences between Black, Gray, and White Box Penetration Tests
Internal vs. External Black Box Penetration Tests
Blac Box Threats Emulated
- External Hacker with little or no insider knowledge
- Rogue Device
- Internal Intruder

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

Need a black box penetration test, check out my company Blue Goat Cyber’s Black Box Penetration Test Services.

Complete Black Box Penetration Testing Video Transcript

Hi, this is Christian Espinosa with Alpine Security. In this video, we’ll cover black box penetration tests. In a previous video, we covered gray box penetration tests. I’ll put the link to that video beneath this one. With a black box penetration test, we have the least amount of knowledge from the scale of black, gray and white. A black box penetration test, you typically know very little about the target, maybe the IP address or the URL. With a gray box, you have a little bit more knowledge, typically user-level knowledge. In a white box, you typically have administrator-level knowledge or access to the schematics, the source code, the design documents, et cetera. Also with black box, this is called unauthenticated often because we do not have any level of access from a user perspective, like gray box or an administrator route level perspective like white box.

A black box penetration test can be used both internally and externally, and we’ll go over more detail of that in a second on the next slide. The threats we’re trying to emulate with a black box penetration test are an external attacker with very little knowledge about your environment, a rogue device, or an internal intruder. We’ll cover those in more detail here in a second. With an external black box penetration test, we’re looking at the perspective from outside your network. We’re testing your public-facing systems. If you’re in an organization where testing the systems that are exposed to the internet … so this could be a firewall, a router, a VPN concentrator, your web server. Anything you have exposed to the internet that your employees can access or your clients can access is what we’re testing from an external black box penetration testing perspective.

What we’re trying to emulate is an external attacker. This could be a script kiddie, somebody in China just scanning and looking to see what they can get into. It can be a botnet that’s just trying to scan for vulnerable systems, or it could be an active attacker trying to get into your environment. An example of what we might test could be your external firewall. If you’re a small organization, and all of your internal systems are Natted through a firewall for instance, you want to make sure that those firewall rules are set up properly, and you’re not allowing inbound traffic. You’re only allowing outbound traffic, and you have some rules in place. As an example, if you type in from the internal network, what is my IP, in Google, you can figure out what your public facing IP address is. This is something we would want to test because if your public facing IP address, which is often your external router or firewall, has a hole in it then the attacker may be able to exploit that hole and get access to your internal environment.

Here on the picture we have, what is my IP, we have 71.14.247.83. As a quick example, if I go to Zenmap, which you can see right here, which is basically Nmap, but a graphical user interface for Nmap. This is just a quick example of reconnaissance. They put it in that IP address here, which we put in, 71.14.247.83. Let’s say I do a regular scan, so I’m looking for holes on your external facing router or firewall, or you could have a next-gen firewall, you could have a UTM, et cetera. Go ahead on click on scan here. This is the first step with penetration testing. We’re trying to identify holes you may have. Right now, I’m just using Nmap with a default setting, which looks for the top 1000 ports.

It looks like we have four ports open, 53, 80, 1111 and 2111. If somebody performed an external black box penetration test against your firewall or external router, this is what they would see. Granted, they should scan all 65,535 ports. But this is the top 1000, and we have four ports open out of the top 1000. We can see here that there’s a web server running, DNS running, a few other things. And now the next step would be to identify a vulnerability and then exploit that vulnerability if possible. The reason this is important because if you have a publicly exposed IP address with a vulnerability, somebody could exploit that vulnerability and potentially pivot from the external facing system. From there, they could pivot to your internal environment and get access to your internal environment or get access to a sequel database or something else. You want to make sure you test your environment from an external perspective.

With an internal black box penetration test, we’re looking at the environment from inside your firewall. Really, we’re trying to emulate two threats, two main threats here. One of them is a rogue device, and one of them is an internal intruder. Basically, and these could kind of bleed together as the same thing because an internal intruder could plant a rogue device. But the idea is what if somebody walks into your environment and they plant a rogue device? As we see here, this is a phone plug on the screen in the picture. Let’s say they plant this device on your network. This device is a rogue device which intercepts your traffic, and can send it out via a cellular network to somebody else. Or it could actually phone home through your network and duplicate the traffic that way. Or it could serve as a pivot point.

There’s a number of things it can do, but basically the idea is can you detect or are you protected against a rogue device or an internal intruder? An internal intruder example that might be, let’s say I walk into a dentist office, I’m waiting for my appointment, I’m sitting in a chair in the waiting room and I’ve got my laptop. I’m kind of bored because I’m waiting a long time, but I noticed there’s an ethernet jack exposed in the wall behind me. Let’s say I plugged my laptop into that jack, and I just started screwing around and see what I can see on the network. If I can scan the network and maybe exploit a device on the network, on that dentist’s network, that’s from an internal intruder perspective.

Those are why we would do a black box penetration test. In summary, what we talked about are black box penetration test. The black is the least amount of information between from gray to white. You have limited knowledge, unauthenticated. A black box penetration test can be used to emulate an external attacker as well as an internal attacker or internal rogue device. That’s basically it. The black box is really the simplest type of penetration test, and it should definitely be something you consider. If you have any questions about black box penetration tests, you can leave them beneath the video. You can also subscribe to our channel. And if you’re interested in a black box penetration test against your environment, you can contact us at www.bluegoatcyber.com. Thanks. Have a good one.

Gray Box Penetration Testing Explained

August 29, 2021 by Christian Espinosa

This blog post is a transcript of Christian Espinosa’s explanation of Gray Box Penetration Testing, which covers the following:

Differences between Black, Gray, and White Box Penetration Tests
Gray Box = Authenticated “User” level tests
Internal vs. External Gray Box Penetration Tests
Often includes Black Box Testing
Gray Box Threats Emulated
- Compromised User Account
- Malicious Insider

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need a penetration test? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete Gray Box Penetration Testing Video Transcript

What’s going on. This is Christian Espinosa with Alpine Security. In this video, we’ll go over gray box penetration tests. These are the topics we’ll discuss. The differences between black, white and gray box. A gray box falls between black and white box penetration tests. So with a black box penetration test, you typically don’t know much about the target other than maybe the IP address or the URL. That’s really about it. A black box is considered unauthenticated. You don’t know much about the target. With a gray box, you know a little bit about the target, pretty much from the perspective of the user, your user on the target. So you have user-level access to the target. With white box, you know quite a bit about the target. So you may have access to the network diagram, schematics, design documents, source code, administrator-level access, et cetera. Black have pretty much little limited access, gray in the middle, then white.

As the next bullet there says, gray box, you have authenticated or credentialed user level access to the system. There’s really two broad categories for gray box penetration testers, internal and external. We’ll go over those in the next couple of slides. The threats we’re trying to emulate, which with a penetration test, you’re trying to emulate some sort of threat. The threats we’re trying to emulate with gray box typically are these two threats we have listed on the slide there. A user account is compromised. So let’s say I’m Larry. I’m a user on your web application. What can the attacker do from Larry’s account’s perspective? Or I’m Nancy, a user on your active directory domain, and my account is compromised via a phishing email. So what can the attacker do from Nancy’s perspective on the internal network? What if Larry is just malicious, or what if Nancy, she’s malicious as well? Those are the threats we’re trying to emulate.

For external gray box penetration tests, typically, and this is where the categories I’ve mentioned, we have external and internal. Typically with external gray box penetration tests, it’s against some sort of web application. A common example as we have here on the slide is a patient portal. So a lot of hospitals and clinics have a patient portal. This is if you’re a patient, you can log on, pay your bill, look at your last visit, look at the details, maybe schedule an appointment, et cetera. With a gray box penetration test, what we’re trying to do is test the patient portal in this scenario from the perspective of, like I mentioned earlier, a compromised user or a malicious user. So if I am Larry and I’m logging on to the patient portal as Larry. From Larry’s account, what can I get access to on the patient portal? If there’s a vulnerability, can Larry, for some reason, exploit that vulnerability and somehow get access to Pam’s account, for instance? Because it would not be good if Larry can horizontally get access to Pam’s account and then read Pam’s medical history. That’s an example of a horizontal privilege escalation.

The other scenario is what if Larry can somehow exploit a vulnerability on the patient portal and get admin or root level permissions? Larry can see everybody’s information, including Pam’s, Sam’s, Dan’s, et cetera. So that would not be good. With a gray box penetration test, we look at the vulnerabilities of the application from the perspective of the user.

Let me give an example here. I’ll bring over a patient portal here. This is just an example. If I go to Google and search for patient portal, you’ll see quite a few of them pop up here. I just went to the first one right here. This is a whatever, NextGen Healthcare, it doesn’t really matter. But right now, if we’re looking at the patient portal and we’re not logged in, and let’s say we do some testing, this would be black box penetration testing. Once we’ve logged in as a user such as Larry, then we would be testing it from a gray box perspective. An example like let’s say from a black box perspective, if I type in tick or one equals one dash dash and I just put whatever here as a test for a SQL injection, that’s a black box test. With a gray box, we would test a lot of different things, but logged on as Larry, as I mentioned.

With Alpine security, we include the black box portion of testing with our gray box because we tested from both an unauthenticated perspective and an authenticated perspective. So that’s an example of an external gray box penetration test.

The other type of gray box penetration test is an internal gray box penetration test. With an internal box penetration test, what we’re looking at is what sort of damage could an internal user do with user level permissions on an internal network inside a firewall such as an active directory domain? If Sally’s computer was compromised or Sally clicked on a phishing email and her account was compromised, from the perspective of Sally’s credentials, which are user level credentials, what could the attacker do? Could the attacker somehow get access to sensitive data? Could they get access to Bruce’s account? Could they somehow find a vulnerability and exploit it on the network that gave them administrator level permission, such as domain admin, et cetera? So we’re looking at it from that perspective, and we’re also looking at from the perspective, like what if a Rodrigo, let’s say, is malicious and Rodrigo wants to steal secrets and send them to China? If Rodrigo is a malicious user, what can Rodrigo get access to using his user-level permissions? That’s the other sort of use case or threat we’re emulating.

Another use case is, let’s say a user’s laptop was compromised. Let’s say Jessica takes her laptop home and her boyfriend who was a spy for Russia, let’s say, gets his hands on the laptop. If the boyfriend, the spy from Russia, gets the hands on Jessica’s laptop and that boyfriend can get into Jessica’s laptop, let’s say the boyfriend’s name is Ivan. Ivan can get into Jessica’s laptop as Jessica, or Jessica leads the laptop unlocked. What sort of damage could Ivan do to that laptop or to the systems the laptop has access to? So if the laptop can VPN into the corporate network, what can Ivan get access to as Jessica? Also, Ivan can try to get access to secret stuff on the laptop. Can he escalate privileges to local admin on the laptop? Can he circumvent controls, et cetera? So again, that is an internal gray box penetration test, and we’re looking at it from the perspective of really two broad categories of threats. A malicious user or a compromised user that really didn’t mean to be malicious but their account was compromised.

As a summary, we talked about these main points here, the differences between black and white and gray. Gray is in the middle, black you have limited information, maybe just an IP address or URL. White, you have a lot of information. Gray, you have user level information and user level access. Which is also authenticated or credentialed. We explained a little bit the differences between internal and external. External is typically with a web application such as a patient portal. We’re testing if we can escalate privileges horizontally or vertically. With internal, we’re testing from a domain user or internal user, typically inside your firewall, and we’re seeing what we can do. Same concept from escalating privileges, horizontally or vertically, and what data an insider or internal user can get access to.

If you have any questions about gray box penetration testing, you can leave them beneath the video. If you are interested in us performing a gray box penetration tests against your environment, either externally or internally, you can contact us at alpinesecurity.com. You can also subscribe to our channel. If you just want to learn more about penetration testing, feel free to reach out to us or take one of our classes.

White Box Penetration Testing Explained

August 27, 2021 by Christian Espinosa

This blog post is a transcript of Christian Espinosa’s explanation of White Box Penetration Testing, which covers the following:

Differences between Black, Gray, and White Box Penetration Tests
White Box = Full knowledge about the target
White Box is typically used during development or system integration
Often includes Black and Gray Box
Threats emulated:
- Poor coding practices
- Supply chain issues

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need a penetration test? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete White Box Penetration Testing Video Transcript

Hello. This is Christian Espinosa with Alpine Security. In this video, we’ll cover white box penetration tests. This completes our series, the three video series of the different colored boxes of penetration tests. We already did a video on both the black and gray box penetration tests. With a white box penetration test, we know the most about the target. Just a quick review. With a black box, we know very little about the target other than maybe the target’s IP address or URL. With a gray box, we know a little bit more than a black box. We often have user-level access to the target such as a user-level account on a web application, or maybe an active directory user-level account. With white box though, we know the most about the target. Sometimes with white box, we have root-level or administrator-level permissions.

We also often have access to data-flow diagrams, entity-relationship diagrams, maybe even the source code, maybe even access to the developers that are actually producing the software, or developing the software, or the product. Typically, with a white box penetration test, this is most often used during development of software or a product. It’s much more beneficial to have somebody from a penetration testing team working with your developers during the development process than waiting until your product is released and then hiring a penetration testing team to poke holes in it after it’s already been released. It costs a lot more money to fix it, and it’s much more difficult to fix after it’s been released. That’s why a white box is typically done as part of the development cycle for a product or software.

It could also be performed during system integration. Let’s say you’re a systems integrator, and you integrate different subsystems from different suppliers. You integrate all that into your overall system. You have to have some degree of trust that your suppliers are actually designing their components to your specifications, and that what you’re getting from them is secure. So before you integrate that, or as you’re integrating that into your overall system, you should do some white-box testing to make sure this component you get for instance, only has the inputs you specify, and the outputs you specify. There’s no extraneous data going through that component or originating from that component.

That would be an example of when we would do a white box penetration test for systems integration. Also, a white box penetration test typically includes a gray box and a black box because as we’re going through this process, and we’re looking at what’s being developed, we often do the test from both the aspect of unauthenticated and user-level access, which is gray. The threats we emulate for a white box, typically we’re trying to discover poor coding practices. A white box perpetration test, as I mentioned, is typically performed during software development. This is the prime time to discover a input validation problem or a balance checking problem. The perfect opportunity is during the development.

As I mentioned earlier, if we wait to hire the penetration testing team until after development’s done, and they find out we have a problem such as a input validation or a buffer overflow attack that our software allows to happen because of a vulnerability, that is much more costly to fix than if we could have identified it upfront. The other threat that the white box penetration test helps with is any issues in the supply chain. As I mentioned earlier, we often do white box penetration tests to a systems integrator, so if one of your suppliers in the supply chain has a vulnerability that is introduced somewhere along the supply chain, and that component makes it into your overall system, this is the perfect opportunity to test this before it’s released again, out to your customers.

If you have any questions about white box penetration testing, you can leave them as a comment beneath this video. If you’re interested in a white box penetration test, you can contact us at www.alpinesecurity.com. I hope you enjoyed this video, and I’ll talk to you later on. Cheers.

The Cybersecurity Status Quo Needs to Change

July 21, 2020 by Christian Espinosa

This is a transcript of the video at the bottom of the post.

In 1997, Apple came out with the commercial Here’s to the Crazy Ones. 20 plus years later, that commercial still resonates with me. Steve Jobs came up with a lot of the material for that commercial based on his life. He always felt like he didn’t quite fit in or was a misfit. He felt like he wanted to challenge the status quo. He also was called crazy a lot for dreaming too big, but instead of trying to follow the status quo or fit in, he embraced his uniqueness and ended up changing the world and having a huge impact. I feel the same way about cybersecurity, because, with cybersecurity, there is a status quo, this movement that we just keep following, but it’s not helping. A lot of people would call me crazy for wanting to challenge the status quo, but the status quo was not working.

And we know this. There’s plenty of evidence of this because of the different data breaches every day. One of the reasons the status quo is not working, or I believe it’s the primary reason is we’ve overly complicated cybersecurity. Instead of focusing on a few things and doing those few things very well, that few things that will reduce the risk the most, we try to get everyone to do hundreds of things. We can’t do hundreds of things very well, and what happens is we ended up doing them all half-assed, really.

I used to work with this guy and I always think of this scenario. I used to work with him and he was working these two projects once, and he was having a little bit of trouble figuring out which one took priority or which one took precedence. So he went and asked his boss, which one of these two projects takes priority? His boss told him they’re both an equal priority. His response was, “Okay. Well, I guess I’ll do both of them half-assed.” It’s the same concept as cybersecurity. If we try to do too many things, we ended up doing them half-assed. We should focus on just a few things and do them very well. Most data breaches are caused by a misconfiguration or an unpatched system. These are two simple things to fix, but you can’t focus on those things if you’re focusing on the other 98 stuff, 98 items that don’t really matter. This time, we challenge the cybersecurity status quo. What we’re doing is not working. We need to think different, as Apple would say. Here’s to the crazy ones.

Here’s to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in the square holes, the ones who see things differently. They’re not fond of rules and they have no respect for the status quo. You can quote them, disagree with them, glorify, or vilify them. About the only thing you can’t do is ignore them because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius, because the people who are crazy enough to think they can change the world are the ones who do.

Helping Your Audience Become More Secure

Sharing Interpersonal Skills For Smart People on Your Platform

Connect On Social Media