I'm confused why you would need DLP if they are encrypted drives like you were asking about earlier.

@Dashrender said in DLP (Data Loss Prevention) solution:

@stacksofplates said in DLP (Data Loss Prevention) solution:

@Dashrender said in DLP (Data Loss Prevention) solution:

@scottalanmiller said in DLP (Data Loss Prevention) solution:

@Dashrender said in DLP (Data Loss Prevention) solution:

@scottalanmiller said in DLP (Data Loss Prevention) solution:

@Dashrender said in DLP (Data Loss Prevention) solution:

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.

@Dashrender said in DLP (Data Loss Prevention) solution:

@scottalanmiller said in DLP (Data Loss Prevention) solution:

@Dashrender said in DLP (Data Loss Prevention) solution:

@scottalanmiller said in DLP (Data Loss Prevention) solution:

@Dashrender said in DLP (Data Loss Prevention) solution:

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.

@Dashrender said in DLP (Data Loss Prevention) solution:

@scottalanmiller said in DLP (Data Loss Prevention) solution:

because the reason to want to do it is almost certainly a bad one.

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.

@JaredBusch said in What Are You Doing Right Now:

@DustinB3403 said in What Are You Doing Right Now:

@srsmith said in What Are You Doing Right Now:

@Dashrender

Still don't know wtf caused it, but the laptop is a Win 7 refurb from 3+ years ago, so it's just not worth repairing.

A new screen might be $12 bucks, what model laptop is it?

not even close.

Yeah depending on the model they usually start around $60.

@scottalanmiller said in Researching OpenDental Software:

So in the above directions, where the heck are we supposed to get the "blank" database from? WTF

From what that page I looked sounded like when you install the trial it stuff up the schema.

I'm honestly surprised it's not built with FoxPro.

https://www.opendental.com/site/sourcecode.html

Tortoise SVN.............

You have to install the trial version to get the initial database tables set up? What is this?

@Danp said in Mocking API Endpoints with Go:

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.

So I had to mock an API in something I'm writing for testing and I figured I'd post this to show you an easy way to do it in Go.

First you need to get the JSON structure for the response you'll be mocking. To do this you can just use cURL or whatever tool you want.

Let's use JSON Placeholder since it's free and doesn't require any authentication. If you go to this URL, you'll see the comments API: https://jsonplaceholder.typicode.com/posts/1/comments

I use this site to convert JSON to structs. If you paste in the JSON data you get a struct like this:

type Comment []struct {
    PostID int    `json:"postId"`
    ID     int    `json:"id"`
    Name   string `json:"name"`
    Email  string `json:"email"`
    Body   string `json:"body"`
}

So we just need to be able to mock this in our unit tests. Here's a small app that reaches out to JSON Placeholder and gets all of the comments that exist for a specific post.

package main

import (
	"encoding/json"
	"fmt"
	"io/ioutil"
	"log"
	"net/http"
)

type Comment []struct {
	PostID int    `json:"postId"`
	ID     int    `json:"id"`
	Name   string `json:"name"`
	Email  string `json:"email"`
	Body   string `json:"body"`
}

func (c Comment) getComment(u string) {

	req, err := http.Get(u)
	if err != nil {
		log.Fatal(err)
	}

	body, err := ioutil.ReadAll(req.Body)
	if err != nil {
		log.Fatal(err)
	}

	error := json.Unmarshal(body, &c)
	if error != nil {
		log.Fatal(error)
	}

	fmt.Println(c[0].Name)

}

func main() {
	var c Comment

	c.getComment("https://jsonplaceholder.typicode.com/posts/1/comments")
}

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:

package main

import (
	"io"
	"net/http"
	"net/http/httptest"
	"testing"
)

type commentTest struct {
	actual   string
	expected string
}

type commentInt struct {
	actual   int
	expected int
}

func TestgetComment(t *testing.T) {
	data := `
	[
  		{
    		"postId": 1,
    		"id": 1,
    		"name": "test name",
    		"email": "test@test.com",
    		"body": "this is the body"
  		},
  	]
	`

	ts := httptest.NewServer(
		http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			io.WriteString(w, data)
		}))

	defer ts.Close()

	var c Comment

	c.getComment(ts.URL)

	var tests = []commentTest{
		{c[0].Name, "test name"},
		{c[0].Email, "test@test.com"},
		{c[0].Body, "this is the body"},
	}

	for _, tt := range tests {
		if tt.actual != tt.expected {
			t.Errorf("got %v, want %v", tt.actual, tt.expected)
		}
	}

	var testInt = []commentInt {
		{c[0].PostID, 1},
		{c[0].ID, 1},
	}

	for _, ti := range testInt {
		if ti.actual != ti.expected {
			t.Errorf("got %v, want %v", ti.actual, ti.expected)
		}
	}

}

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").