Ultimately the client decided it wasn't worth the hassle of buying/deploying DLP just so they could use USB sticks.
Instead - they will email or OD4B or Slack the files around that they nee

So in this case, it seems like the insurance requirement turned out to be a good thing. Pushed them to do things in a controlled, logical way rather than a crufty, silly, legacy way.

yes - sure, that's true, but come on, we both know that's not what the real intention of this request is/was - or at least I personally don't believe that someone at the insurance company has a personal vendetta against USB storage - but really, they are trying to prevent insurance data from being leaked... and when they were considering how things get leaked - they crazily started and stopped with USB storage.

Well, I don't know. Let's think about it... USB sticks being allowed is an extremely weird thing to want to keep. It's a super dangerous activity with little reason to be allowed in the modern world. So anyone doing it is likely to be doing loads of risky, stupid things because the reason to want to do it is almost certainly a bad one.

The goal is easily to heavily punish bad behaviour and/or encourage rethinking bad decisions. It's isolated, but it worked. Something risky and dumb turned into something modern and practical in a pretty predictable way. The insurance company pushed them to fix a process that you as IT alone could not do.

Do assume insurance companies are dumb when they do something that turns out really smart. They do their homework.

Their stated reason for wanting no USB was - "so our data doesn't walk out of your company." So while what you say has merit - it's not ever been a reason given for it's discontinued use... and hell, if it had.... if they had said - "you know, USB is legacy and carries the risk of passing infections along much more easily than say - emailing the data to someone, or using Dropbox, etc, so we'd much rather you share our data via those processes than via USB - and we'd like you to disable USB because reasons already mentioned" then the client would have likely gone that way from the start.

They can most likely track where the data was leaked through email or something else like Dropbox. That's almost impossible with USB drives without something like DLP. So yes while it doesn't necessarily stop someone from leaking data that way, it's at least somewhat traceable.

oh? how is that more traceable through email or Dropbox? Unless you're saying those things HAVE logs.. what if they don't?

I guess you could possibly find a service that doesn't? I mean I didn't say it was guaranteed that there were, just that it's likely.

Ultimately the client decided it wasn't worth the hassle of buying/deploying DLP just so they could use USB sticks.
Instead - they will email or OD4B or Slack the files around that they nee

So in this case, it seems like the insurance requirement turned out to be a good thing. Pushed them to do things in a controlled, logical way rather than a crufty, silly, legacy way.

yes - sure, that's true, but come on, we both know that's not what the real intention of this request is/was - or at least I personally don't believe that someone at the insurance company has a personal vendetta against USB storage - but really, they are trying to prevent insurance data from being leaked... and when they were considering how things get leaked - they crazily started and stopped with USB storage.

Well, I don't know. Let's think about it... USB sticks being allowed is an extremely weird thing to want to keep. It's a super dangerous activity with little reason to be allowed in the modern world. So anyone doing it is likely to be doing loads of risky, stupid things because the reason to want to do it is almost certainly a bad one.

The goal is easily to heavily punish bad behaviour and/or encourage rethinking bad decisions. It's isolated, but it worked. Something risky and dumb turned into something modern and practical in a pretty predictable way. The insurance company pushed them to fix a process that you as IT alone could not do.

Do assume insurance companies are dumb when they do something that turns out really smart. They do their homework.

Their stated reason for wanting no USB was - "so our data doesn't walk out of your company." So while what you say has merit - it's not ever been a reason given for it's discontinued use... and hell, if it had.... if they had said - "you know, USB is legacy and carries the risk of passing infections along much more easily than say - emailing the data to someone, or using Dropbox, etc, so we'd much rather you share our data via those processes than via USB - and we'd like you to disable USB because reasons already mentioned" then the client would have likely gone that way from the start.

They can most likely track where the data was leaked through email or something else like Dropbox. That's almost impossible with USB drives without something like DLP. So yes while it doesn't necessarily stop someone from leaking data that way, it's at least somewhat traceable.

We simply disagree here - it's legacy, sure, but I wouldn't call it bad. though - of course in typing this - at least with email/dropbox/OD4B, etc there is much less chance of a tag along virus (short of the file itself being infected) compared to a USB stick... ok fine - you win, it's probably a bad idea to still do that today.

So Suzie office worker finds a "free" USB drive in the parking lot and plugs it into her computer.

Allowing uncontrolled USB drives is a big security concern. And a policy saying you can only use company ones is useless because policies don't stop the thing from happening once someone breaks the policy.

I know that Postman provides the ability to perform this type of API testing. Has anyone tried this feature?

I'm sure it does. The problem there though is if you're running in a pipeline you'd have to somehow get Postman downloaded, set up, and configured automatically to test against it. This is just in the standard library so you can unit test in your pipeline automatically.

However, when you're unit testing, you don't want to have to actually reach out to the site. That's more of an integration test. So to be able to test our method, we need to mock that API endpoint. So to do that Go has a test server built in for this reason. You can use it like this:

This particular test happened to be a little long because of the two types of data. There might be an easier way by building one struct for both the int and string types but this way was easy to write really quickly.

I don't want to get into how testing in Go works. However, the important line is ts := httptest.NewServer(). That's where we define our test server. We tell it to take data and put that into w which is our response. So when we run our c.getComment() method we wrote earlier, we can pass ts.URL which is the URL of our test server and we will get a response of whatever is in data. Then we just compare the results to what we expect them to be and if they aren't the same the test will fail.

It's good to note that if your JSON data is long, you probably don't want to put it in line. So you could store it in a file alongside your code and pass the data in that way. You would just use something like data, err := ioutil.ReadFile("./data.json").