DEV Community: koduki

Zero Trust Network for comfortable WFH

koduki — Sat, 04 Apr 2020 08:28:10 +0000

TL;DR

Zero Trust Network is post VPN for remote access.
Base on HTTPS and Context awareness access Control(CAAC)
Big paradigm shift from Firewall boundary to ID boundary

What is Zero Trust Security?

Do you know Zero Trust Security?

Now many people work from home due to Coronavirus disease (COVID-19).
This is very very bad situation for your life, health and global economy.
However, it is good opportunity to consider about remote access.

Roughly speaking, we can understand Zero Trust Network is post VPN.
This concept is simple, "Never trust, anywhere and anyone".

Traditional VPN and Offie network are base on trust networks.
It made trust network in office and DC. These physical facilities are connected trust network like dedicate line. And they are protected Firewall.
Firewall is the Great Wall to separate trust networks and untrusted
networks. Security solutions take care a lot about access from untrusted networks.

Image: Traditional office networks

VPN is only way to connect trust networks through untrusted networks as the special solution.

On the other hands, Zero Trust Network is base on untrusted networks.
Today, remote access is very natural requirement. And Attacks have gotten more malus continuously. We have to take care about access from even trust network. That's why zero trust network start from untrusted network. So they can provide same security models whether trust networks or untrusted networks.
This approach protect systems by IDaaS like AzureAD or Google Cloud Identity instead of network firewall.

Image: Zero Trust networks

Whether from office or home, each access is controlled by Context like user account, device, location and target application.

Why do we need post VPN?

Before deep diving to Zero trust network, let me explain why do we need post VPN.

There is two issues.

Performance
Difficulty of right access control
Consistent security policy

Performance

VPN performance is not so good. Because encryption is heavy task and it has latency problem. Even we want to connect to SaaS, we need access data center as VPN access hub. It is an extra connection.

In addition, capacity plan is difficult. Because in the normal situation, only very few people will access from remote. However disaster situation like now, remote access will increase dramatically for BCP.
Honestly specking, it's difficult to always secure enough capacity for emergency.

Difficulty of right access control

VPN looks internal access, so it difficult to control office or home by application side.
For example, if you want only approve e-mail and some reporting tool from remote but you don't want to access business application which includes customer information. This requirement is natural. However if you want to realize, you may need to make or change firewall and network configuration. You need take care about network segment of each application. If you want to change such a remote access privilege level depending on role or person, you also need to take care about IP address which is distributed by VPN. If you want to utilize VDI(Virtual Desktop Infrastructure), issue will be complex more and more.

This is a big problem.

Consistent security policy

We should use consistent security model to avoid complexity.
However, tradition office network is difficult to do it.

First of all, it only provides security through trust network. Because almost security solutions like AV, EDR, CASB, device management are deployed on data center. This mean remote device is only applied through VPN. If VPN is not connected, that device is not secure. The problem is caused by that only the office is the first citizen and remote access is not.

Second is SaaS. Office networks changed. We utilize not only intra system but also many SaaS product for our business environment. In this case, we also take care about SaaS access control and generally it is separated from current office configurations.

From these three reasons, we need to consider about new security model.

Context-Aware Access Control (CAAC)

CAAC is key component for zero trust security network.
Role base access control (RBAC) verify user/role and target application. This is a better approach than just Network access control (NAC). Generally, we combinate NAC + RBAC. But it still not enough.

CAAC verify user/role, device, location and target application. Location is typically network. So CAAC realize same control with NAC + RBAC by only single security control.

Below is an example scenario.

This sales staff can access to their customer management (CRM) system from office.

But, even same person and same device can't access to their CRM from office.

And he can access Office 365 like e-mail and one drive from home. However ind this case, he is required additional authentication like MFA.

CAAC realize such a control easily. If we want do same control by NAC + RBSC, it is very complex configurations.

Conditional access of Azure AD and Cloud IAP of GCP are popular implementation of CAAC.

Office network with Zero Trust Network

Zero Trust Network is ID base security boundary. It is able to apply same control both office and home by CAAC.

To utilize this control, typical we use cloud security for endpoint security like AV, EDR, CASB, device management.
These tools can apply security whether trust networks or untrusted networks.

Form CAAC and Cloud Security, we can resolve Difficulty of right access control and Consistent security policy.

In addition, Zero Trust Network doesn't apply extra encryption. Because every application should support HTTPS/TLS. Then they don't need extra overhead by encryption.

Someone may afraid HTTPS is less secure than VPN, but it's not true.
VPN is based on TLS. So security level is completely same with HTTPS. Sometime VPN also support device trust. But IDaaS like Azure AD also support device trust with Intune. So we can say "It's completely same with VPN".

Finally, zero trust security network doesn't take care about remote access or NOT. This mean everyone has capability of remote access. It is just control. So even if remote access increase by BCP, capacity is always enough.

Conclusion

VPN was good solution. However it has some issues today.
We should shift from traditional network model to zero trust networks.

Of course, migration is not easy. However always improvement is only way to keep security.

We should be consider everything about security.

Happy Hacking!

Technology landscape for Identification Management System

koduki — Thu, 11 Jul 2019 06:31:01 +0000

Preface

Identification Management System is very important component for both enterprise and consumer.

Especially, MFA is very hot topic. Anyone know about MFA. But do you know MFA clearly? It is NOT MFA to just use SMS or biometrics.

Let me explain the technology trend for Identification Management System like MFA, Risk-based authentication, CAAC and SSO.

Authentication/Authorization

As you know Auth has two mean — Authentication and Authorization. These are very similar word. But different is simple.

Authentication is Identify. This mean "Who are you?". Authorization is Access Control. This mean "What is permitted for you?"

For example, OpenID is a technology for Identify and OAuth is a technology for Access Control.

Multi-Factor Authentication(MFA)

MFA/2FA is very hot technology. But it doesn't mean to use SMS or biometrics. And please be careful about difference with two-step verification.

According to NIST Special Publication 800-63-3 Digital Identity Guidelines, there is three factor of authentication.

Something you know
Something you have
Something you are

"Something you know" is knowledge which is known only right user. Password or PIN are typically examples.

"Something you have" is property which is had only right user. SMS(Phone Number), mail address, token generator, hardware key/card, IP address and Geo-location are typically examples.

"Something you are" is biometrics. Fingerprint, face and iris are typically examples. Smartphone and AI help this area today.

MFA is a combination of over two factor. This mean 2nd password is NOT 2FA. It's only two-step verification with single factor. Because password and 2nd password are both "Something you know" .

Single factor is easy to hack by same way. So combination is important.

Especially almost attacker already knows about right ID and password. Then we need to additional factor for important operation.

Fraud detection

Monitoring and Fraud detection is very important part for Identification Management. Because attacker already knows about right ID and password . But we need defect fraud.

Internet Protocol Address (IPA) Location, Geo-Location and time are important information for this.

Because if someone accessed in USA five minutes after being accessed in Japan, maybe it's illegal access. Such a access should be rejected.

Risk-based authentication

Risk-based authentication is improvement of fraud detection. Sometime we use new PC and we move to another location.

If it's only provided fraud detection, we can't log-in in such a situation. It is NOT user-friendly.

So Risk-based authentication manages such a irregular access patterns as risk. And it requires more additional authentication like SMS, e-Mail and so on. This is very useful function.

In general, smartphone industry call this behavior as two-step verification with SMS authentication.

Context-aware access Control (CAAC)

Context-aware access control is mainly for enterprise system. It is a extetnion of role-based access control (RBAC).

It dynamically determines access capability according to the following factors.

User
Device
Location
Target system
Target operation

For example, we can control access level by office or home. And it is able to require additional authentication factor like hardware-key when user is on their home.

Azure AD Conditional Access and Google Cloud IAP provide this feature. It's key component for Zero Trust Security. This is only way for security control for SaaS. Because Cloud Age is every access is Remote Access . VPN is NOT enough now.

Single Sign On (SSO)

SSO is not new technology for Enterprise. LDAP and Acitive Direcotry and each cloud vendor's IAMs provide this function. It's natural way for enterprise systems.

Maybe someone may think that SSO is for usability for employee. But it's NOT correct.

SSO is for security. As you already know, Identification Management is very complex system. It's required a lot of features like MFA, Fraud Detection and monitoring and Context-aware access.

If we don't use SSO, individual system has own account. And user needs to manage their password. It looks secure.

But it's difficult to make the best auth features for individual systems and it's not realistic scenario to be managed many passwords properly by every user. Maybe they use same password for every system to help their brain memory. It's not secure.

So we use SSO for security with trusted ID systems. This is the best practices!

Conclusion

This diagram is summary of Identification Management System.

Most importantly, Identification Management System is very complex. We shouldn't make by ourself.

If you make a system for consumer, you should use Social Service ID like Google, GitHub, Twitter and Facebook with OpenID Connect.

And if you make a system for business, you should use IDaaS like AzureAD with SAML 2.0 or OpenID Connect.

It's the best practice and only way to avoid Identify Issues, I believe.

Happy Hacking !

The seven rules for continuous UnitTest

koduki — Sun, 07 Oct 2018 03:33:07 +0000

Introduction

Do you write UnitTest on your project? Are UnitTests ran every time?

I completely thought it's same thing to write UnitTest and write "continuous" UnitTest.
But it is difference.

Almost engineer know UnitTest is important. So they write UnitTest.
But I saw such a UnitTest is abolish again and again.
Why? Because they are very slow, they are difficult to maintenance, and they are broken.

Continuous UnitTest needs to meet some requirements.
You can satisify this requireents by the following rules.

Run always
Keep portability
Keep repeatability
Avoid slow tests like a RDB, emulation, and so on
Don't use your eyes
One UnitTest, One point of view for a test
Use readable name

In this article, I explain about these rules.
I explain based on Java, Maven, JUnit. But You can apply to other languages.

The seven rules

Run always

This rule is the most important.
You should run UnitTest every time, when you build your code.

Don't use -Dmaven.test.skip=true!! Please...

If you can always run all unit tests, they are Continuous UnitTest code.
But if you can't do it, you need modify it.

Keep portability

Portability is important.
Unit Test isn't only ran on you PC, but also is ran on other environment.
Other environment is coworker's PC, CI environment and future your PC.

For portability, you need to only use under your project directory.
You shouldn't use /var/foobar and D:\foobar as test data directory and so on.
Please use under target directory or src/test/resources/.

Keep repeatability

Portability is important for run always.
Your code should be ran without any manual operations like a removing test data and so on.

In generally, such a initialize or cleanup code should be ran on setUp or tearDown.

Avoid slow tests like a RDB, emulation, and so on

You should avoid slow test like a RDB test and using emulator.
Such a test is very useful. You should do it. However it's integration test.

JUnit also support integration test.
You can use real DB by DBUnit. You can use arquillian. Today, you can use even Docker.

I love it. But these test is slow.
If tests are slow, you will not run all UnitTest every time.

So, you should separate such a test as Slow Test.
I recommend make a slow-test profile or use maven's integration-test phase.
And you can ran it when build on CI environment or before commit.

Don't use your eyes

Don't use your eyes for UnitTest!

UnitTest should check assertion automatically.
You shouldn't use your eyes to check logs, standard out, file output and so on.
Please use assertThat, assertEquals and so on. It's JUnit's role.

Maybe following article helps you.
How do you write "Production Code" for UnitTest?

One UnitTest, One UnitTest, One point of view for a test

Each test should be check only one point of view.
If there are many points of view for a test case, it's difficult to check which test is failed.

This is not manual tests. You don't need to decrease test operation cost.
You can make a test case for only one point of view.

Please avoid only one test case per method.

Use readable name

Please use readable name.
You should avoid like a test001, test002, test003...
Because anyone can't understand a expectation of its method.

Naming is important as well as production code.

Maybe BDD style helps you a lot.
You should use method name, condition and expectation as test name.

Summary

I think almost rule is not difficult.
Maybe many people think almost rules are very natural.
You may even think it is unnecessary as it is common sense.

But it's important to be clearly rules.

Especially, many people don't separate UnitTest and IntegrationTest.
JUnit tests are managed as just JUnit tests. It's not good.

I believe simple rules support smooth communication!

Happy hacking!

How do you write "Production Code" for UnitTest?

koduki — Sun, 30 Sep 2018 22:48:53 +0000

Introduction

UnitTest is very important for keeping code quality.
So almost project require to write UnitTest.

As a result, I will review strange UnitTest or I will be asked them about "I can't write UnitTest!".

Why? Because they don't consider about production code for UnitTest.
They only consider about UnitTest code for UnitTest. This is not good.

We should divid "business logic" and "uncontrolled value" from production code for writing UnitTest. This is also good for "readability".

Basic rule is only two.

Sepalate "business logic" and "uncontrolled value like a I/O, date, random"
Inject dependency by argument, constructer, non-private fields

In this article, I explain how do you write production code for UnitTest.

Typically example

Firstly, I explain typically cases.

Case 01: "I want to output to standard output"

You should sepalate the logic and the output method like a System.out.println or Logger.info.
You make a simple method for building "output string".

// Production Code:

public class Example01Good {
    public static void main(String[] args) {
        String message = args[0];
        System.out.println(makeMessage(message));
    }

    static String makeMessage(String message) {
        return "Hello, " + message;
    }
}

// UnitTest Code:

@Test
public void testMakeMessage() {
    assertThat(Example01Good.makeMessage("world"), is("Hello, world"));
}

Case 02: "I want to use random number"

Random number is not able to fix result.
So we need to sepalate the logic and the number generator.
This is a simple dice game logic for checking "Odd" or "Even"

// Production Code:

public class Example02Good {
    public static void main(String[] args) {
        System.out.println(check(throwDice(Math.random())));
    }

    static String check(int num) {
        return (num % 2 == 0) ? "Win" : "Lose";
    }

    static int throwDice(double rand) {
        return (int) (rand * 6);
    }
}

// Test Code:

@Test
public void testCheck() {
    assertThat(Example02Good.check(1), is("Lose"));
    assertThat(Example02Good.check(2), is("Win"));
    assertThat(Example02Good.check(3), is("Lose"));
    assertThat(Example02Good.check(4), is("Win"));
    assertThat(Example02Good.check(5), is("Lose"));
    assertThat(Example02Good.check(6), is("Win"));
}

Case 03: "I want to calcurate calendar like tomorrow, 1 year ago or later"

Calculating calendar is very general code. But current time like today is uncontrolled value.
You need to sepalate the calendar Calculation logic and getting current time.

You can use method arguments like a random number. This is good pracitice.
But sometimes getting current time is used on many places. In such a case, you can also use factory pattern.

// Production Code

class SystemDate {
    public LocalDate today() {
        return LocalDate.now();
    }
}

public class Example03Good {
    SystemDate systemDate = new SystemDate();

    public LocalDate tomorrow2() {
        return systemDate.today().plusDays(1);
    }
}

// Test Code

@Test
public void testTomorrow2() {
    Example03Good target = new Example03Good();
    target.systemDate = new SystemDate() {
        @Override
        public LocalDate today() {
            return LocalDate.of(2017, 1, 16);
        }
    };
    assertThat(target.tomorrow2(), is(LocalDate.of(2017, 1, 17)));
}

Case 04: "I want to manage File I/O"

Basically, this is same with Standard I/O case. You should sepalate the logic for building Text or Binary and the logic for read or write.
This is pretiy good.

But sometimes you need very many text size, checking line order and so on.
In such a case, you can use Reader/Writer and InputStream/OutputStream to sepalate logic and I/O.

// Production Code

public class Example04Good {
    public static void main(String[] args) throws Exception {
        System.out.println("hello");
        try (Reader reader = Files.newBufferedReader(Paths.get("intput.txt"));
                Writer writer = Files.newBufferedWriter(Paths.get("output.txt"));) {
            addLineNumber(reader, writer);
        }
    }

    static void addLineNumber(Reader reader, Writer writer) throws IOException {
        try (BufferedReader br = new BufferedReader(reader);
                PrintWriter pw = new PrintWriter(writer);) {
            int i = 1;
            for (String line = br.readLine(); line != null; line = br.readLine()) {
                pw.println(i + ": " + line);
                i += 1;
            }
        }
    }
}

// Test Code

@Test
public void testAddLineNumber() throws Exception {
    Writer writer = new StringWriter();
    addLineNumber(new StringReader("a\nb\nc\n"), writer);
    writer.flush();
    String[] actuals = writer.toString().split(System.lineSeparator());

    assertThat(actuals.length, is(3));
    assertThat(actuals[0], is("1: a"));
    assertThat(actuals[1], is("2: b"));
    assertThat(actuals[2], is("3: c"));
}

Fundamental Concept

In this section, I explain more deeply.

Sepalate logic and I/O

Most importantly, you should seplate logic and I/O every time.
This is important desigin for UnitTest.

Let's take an example of a simple program for "getting text from command line arguments and print out to standard out".

public class Example01Bad {
    public static void main(String[] args) {
        String message = args[0];
//         String message = "World"; // for debug.
        System.out.println("Hello, " + message);
    }
}

Maybe, this is the most simple code. I beleave you write down same code firstly.
for debug comment is funny.

Next, let's write UnitTest.

/**
 * Super bad code
 */
@Test
public void testMain() {
    String[] args = {"world"};
    Example01Bad.main(args);
}

This is a super simple. But there is NO assertion! So this UnitTest require to check True or False by your eyes!
Do you think this is a joke? Unfortunatly, I see such a UnitTest on real project again and again...

Of cource this code is terrible. More better people write blow code.

/**
 * Bad code
 */
@Test
public void testMainWithSystemOut() {
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    System.setOut(new PrintStream(out));

    String[] args = {"world"};
    Example01Bad.main(args);

    assertThat(out.toString(), is("Hello, world" + System.lineSeparator()));
}

This code hook StandardOut. It is not bad.
You can run it as UnitTest perfectly. But it's complex jsut a little.

If you can't modify target production code, you should write it.
However if you can change production code, UnitTest becomes more easily.

// Good production code
public class Example01Good {
    public static void main(String[] args) {
        String message = args[0];
        System.out.println(makeMessage(message));
    }

    static String makeMessage(String message) {
        return "Hello, " + message;
    }
}

I sepalate "building message logic" as makeMessage method. So UnitTest becomes following.

// Good test code
@Test
public void testMakeMessage() {
    assertThat(Example01Good.makeMessage("world"), is("Hello, world"));
}

This is a very simple. And it's perfect as UnitTest.

You might think it strange, because this code doesn't do any test about StandardOut.
Exactly. But it's not necessary as UnitTest.

Basically, Checking bussiness logic is the most impotantly in UnitTest.
Sysmte.out.println and Logging library is standard or popular library.
That means their code quality is keeped by other tests. You are only careful about your business logcic.
Of course, you also need to check about Standard Output and so on. But it is integration test.

Don't initilze uncontrolled values directly

You should not initialize uncontrolled value like a randome number, date, RPC(WebAPI), DAO on your each method.
Please apply the concept of DI(Dependency Injection).

Let's take an example of a method for calculating tomorrow.

public class Example03Bad {
    public LocalDate tomorrow() {
        return LocalDate.now().plusDays(1);
    }
}

Naturally, this code is not able to do UnitTest. Because LocalDate.now() value changes every time.
So LocalDate.now() is uncontrolled value. This is a typical beginner's trap.
You need to sepalate it from business logic. The most simple solution is to use method arguments.

public LocalDate tomorrow(LocalDate today) {
    return today.plusDays(1);
}

So you can fix test code follwing.

@Test
public void testTomorrow() {
    Example03Good target = new Example03Good();
    assertThat(target.tomorrow(LocalDate.of(2017, 1, 16)), is(LocalDate.of(2017, 1, 17)));
}

This is enough. But if getting current time is used on many places, you can also factory method pattern and stub.
Firstly, you make factory class which has a method today() to return LocalDate.
Next, you set it on target code field.

Return value of today() is depends on implementation. In production, it is LocalDate.now().

class SystemDate {
    public LocalDate today() {
        return LocalDate.now();
    }
}

public class Example03Good {
    SystemDate systemDate = new SystemDate();

    public LocalDate tomorrow2() {
        return systemDate.today().plusDays(1);
    }
}

In test code, you use stub instead of LocalDate.now().

@Test
public void testTomorrow2() {
    Example03Good target = new Example03Good();
    target.systemDate = new SystemDate() {
        @Override
        public LocalDate today() {
            return LocalDate.of(2017, 1, 16);
        }
    };
    assertThat(target.tomorrow2(), is(LocalDate.of(2017, 1, 17)));
}

The key is to use package scope instead of private scope or you should initialize by constructor.
If you use private scope, you need a mock framework and so on.

Summary

Basic rule is only two.

Sepalate "business logic" and "uncontrolled value like a I/O, date, random"
Inject dependency by argument, constructer, non-private fields

This is not difficult. But sometimes biginner doesn't know it.
In addtion, TDD(Test Driven Development) and Test First force you to write such code.
It is a reasn that TDD is populer.

And functional language is more strict style about side effect. Let's try to study also it.