architecture

CCSP and CCAK, not versus: build your cloud security expertise path based on your needs.

Last week (ISC)² published a blog post on the choice between CCSP and CCAK.

You can find it here: https://www.isc2.org/articles/CCSP-versus-csa-ccak.

“What is the right certification for you?”

The main title of the (ISC)² article on CCSP vs CCAK is “CCSP Certification vs. CCAK Certificate: What Are the Distinctions?”

That’s exactly what you get. A list of technical differentiators between CCSP and CCAK, but according to (ISC)².

But if you hope to get an actual answer to what the right certification is, for you… they forget to ask …you.

What do you think would be the conclusion, if you ask that question to either one of the contestants while you compare 2 certifications? Of course each party will simply draw the conclusion that their own certification is the best choice.

To answer the most important question, the dilemma CCSP or CCAK, is simple: do you need technical or audit skills for cloud security?

The answer

In essence, the answer is simple:

  • if you need cloud audit skills, dive in to the Cloud Security Alliance (CSA) and ISACA Certificate CCAK.
  • if you want to have architect level technical cloud expertise and knowledge, choose CCSP
  • if you want cloud security knowledge, in basic or advanced hands-on, there are other choices to start with (more about it below)

So, if you ask the question “what is the right certification for you”, you immediately know that there is no right answer, but there are many options.
Options for a multi level expertise roadmap in cloud security, based on your current skills and your future goals.

If you like a tough challenge: why not jump into the CCAK or CCSP, CCSP or CCAK, whatever, right away.

But if you would like to boost your chance of success… take a deep breath and better plan smartly.

And don’t start with CCSP/CCAK, but prepare your track towards CCSP/CCAK first.

First some background to plan your roadmap

Setting expectations

Just to set expectations, this article only focuses on the personal education and certification options, offered by (ISC)², ISACA and CSA. Including other education provider would lead us too far.
There are way more other (cyber)security certifications available, but we focus on the cloud security track, which limits the options…

Feel free to comment with other options for cloud security training. I’ll update the article where relevant.

CSA CCSK

The Cloud Security Alliance launched the CCSK in 2011. And as they explained here, “the CCSK was quite literally the industry’s first examination of cloud security knowledge when it was released back in 2011. “

The CCSK is an easy entry, high level introduction to Cloud Security, and it doesn’t require you to have deep technical cloud security expertise.

But it still is a nice baseline for the cloud security essential knowledge.

(ISC)² – CCSP

In short: CCSP = CISSP [by (ISC)²]+ CCSK [by CSA]

The long version is explained in the (ISC)² article comparing CCSP and CCAK.

  • CCSP = Certified Cloud Security Professional
  • You need at least five years of cumulative, paid work experience
  • CCSP is pretty much the same level of difficulty as CISSP, but has focus on cloud security.

The CCSP was launched in 2015, as a cooperation between (ISC)² and CSA. (see CSA press release here), a couple years after the CCSK launch in 2011.
The CCSP is the bigger brother of the CCSK, more advanced, and as CSA rightfully mentions in there CCSK-CCSP comparison blog, the CCSP is on the level of CISSP with a major cloud flavor.

That’s where the dummy math description comes from…

CCSP = CISSP + CCSK.

But CCSP certainly is not an entry level exam.

More information:

ISACA & CSA – CCAK

CCAK = CISA [ISACA] + CCSK [CSA]

CCAK (Certificate of Cloud Auditing Knowledge) is cohosted by ISACA and CSA.
And then you immediately know the approach is different than the approach of (ISC)².

ISACA (Previously known as the Information Systems Audit and Control Association®) stems from audit.
CSA focuses on cloud security.

That’s exactly what CCAK is about : cloud security audit.

See here:

As ISACA mentions on their product page: “The Industry’s First Global Cloud Auditing Credential”.

CISSP

For completeness, I mentioned the CISSP ( Certified Information Systems Security Professional).
I don’t think it needs a lot of explanation, it’s pretty much the reference standard for IT Systems security. (ISC)² references it as “The World’s Premier Cybersecurity Certification”.

It’s a pretty heavy exam, and it does require at least 5 years professional security experience. This is not an entry level exam.

More info: https://www.isc2.org/Certifications/CISSP

SSCP (Systems Security Certified Practitioner)

Due to the experience requirements, CISSP might be a tough credential to start with, although you can pass the exam, and continue to build your experience to grab the CISSP title…

If you want the plan your credentials the smart way, or you’re fresh in cyber-, information or IT-security, you better start with SSCP.

That the little brother of CISSP, and it’s an excellent way to step up to CISSP. More info: https://www.isc2.org/Certifications/SSCP

Where to start?

Cybersecurity & Information security essentials

As explained earlier, for tech skills in cyber-, IT and information security: look into SSCP first.

(Then step up to CISSP.)

Cloud security essentials: CCSK

Now it’s obvious what your first step in cloud security education should be: CCSK.

The CCSK is the perfect introduction to cloud security essentials.

Although it’s very helpful to have some technical IT basic knowledge, the CCSK is very accessible for general audience.

To prepare for the CCSK, you can follow classes or self-study via a completely free preparation toolkit.

Source: CSA CCSK v4 exam (https://cloudsecurityalliance.org/artifacts/ccskv4-exam-prep-kit/)

You can buy a double-try access ticket for the CCSK online exam (60 questions, 90 minutes), so if you would fail the first attempt, study again and retry the exam.

Then plan your track: only technical (no interest for audit) or audit, or both

Only technical

If you focus on technical expertise in cloud security, CCSP is a reference standard (at least, on of them…) .

As mentioned: CCSP = CISSP + CCSK.

So the track is clear

  • After passing the CCSK exam,
  • Take the CISSP exam
  • then take the CCSP

This is the easier route if you already have 5yr+ experience. It’s not the cheapest route, as you pass the CISSP first, but it’s worth the effort. (you only need to pay 1 yearly fee at (ISC)², so after 1 certification, … no extra cost in yearly membership fee)
For junior, less experienced, security engineers, start with SSCP before jumping into CISSP, and then CCSP.

Audit

When you target IT security audits, you need to take a different route depending your background.
Having the CCSP/CISSP background is extremely useful to boost your career in audit.

But for the CCAK, the core audit baseline is CISA.

Keep in mind, similar to CISSP and CCSP, CISA has the same requirements regards professional experience, 5 years.

But if you’re a ISACA CISA, you can add CCSK to the track and land on the CCAK.

Both?

Then it’s obvious, first tech, then audit, meaning a smart combination of

  1. CCSK
  2. (SSCP > ) CISSP
  3. CCSP
  4. CISA (or alternative)
  5. CCAK

Alternative routes

ISO27001 Implementer & Auditor

And alternative route to the auditing experience is ISO27001 auditing, but you’ll need some implementation experience before you can audit.

CISM

Within the ISACA portfolio, the CISM (Certified Information Security Manager), covers the same areas as most ISO27001 (lead) implementer courses.

Which can be helpful to ramp up for the CISA audit part, to gain some hands-on in IT & Infosec governance.

Visualizing your cloud security education roadmap

Lots of blah for a simple choice?

Allow me to visualize the options…

The difference between “certification” and “certificate”, does it really matter?

In it’s blog post (ISC)² tries to put CCSP above CCAK by saying “CCSP is a certification; CCAK is a certificate.”

And they continue “A certification recognizes a candidate’s knowledge, skills, and abilities, typically framed by a job role, while a certificate’s scope is narrower and only documents training course completion. A certification often requires continuing professional education (CPE) to stay in front of trends, while a certificate’s body of knowledge does not evolve over time or require CPE credits to maintain.“

And their explanation is at least flawed and cutting corners to benefit CCSP.

There are many explanations and interpretations of “certification”, depending the context.
But in essence, “certification” is a process and a certificate is a document (the result).

When you certify for “CCSP” at (ISC)², you need to comply with the CCSP condition and then get a document, your CCSP certificate.
Idem for CCAK, you need to comply with their conditions.

Both the certification process for CCSP as the process for the CCAK are used by other similar education providers.

Eg, PECB, ISACA, EC-COUNCIL, … and others require to pay a yearly fee, keep CPE/CPD (continous professional education or development). Some yearly fees are cheaper as others.

Like CSA, Microsoft and others ask for a 1 time exam fee, and then update the exam on longer term, not yearly, and do not require a yearly maintenance fee.

It’s a choice of the certificate owner, how the evaluation and exams are done.

Some of them comply to the ISO17024, and education standard. There are huge benefits to comply (like increased credibility, compatibility with other certifications, …). But it’s not mandatory.

(ISC)² uses an exam, with experience requirement and continuous education once you pass the exam, but you do not need to pass the exam again, unless it’s upgraded to a new build or major version.

But CSA does exactly the same, for example when CCSK was upgraded from v3 to v4, you needed to pass the exam again.

Not on a yearly basis, but the program is updated, the exam is updated… on a regular basis, without yearly fee.

It’s rather a (small) financial effort, not of significance for most companies paying the bill. (Although as an individual, the cost of certification can become a serious burden…)

And it’s certainly not relevant when choosing between CCSP and CCAK. CCAK is cheaper, as referenced in the (ISC)² comparison chart.

References

(ISC)²: CCSP Certification vs. CCAK Certificate: What Are the Distinctions?

Cloud Security Alliance (CSA)

CSA Certificate of Cloud Security Knowledge (CCSK)

CSA & ISACA CCAK

CCAK learning material

CCSK vs CCSP

Vocabulary (alphabetical)

CCAK: Certificate of Cloud Auditing Knowledge (https://cloudsecurityalliance.org/education/ccak/)

CCSK: Certificate of Cloud Security Knowledge (https://cloudsecurityalliance.org/education/ccsk/)

CCSP: Certified Cloud Security Professional (https://www.isc2.org/Certifications/CCSP)

CSA: Cloud Security Alliance (https://cloudsecurityalliance.org/)

(ISC)²:  International Information System Security Certification Consortium (https://www.isc2.org/)

Note-to-self: #ZeroTrust #maturity model assessment by #Microsoft

Have you ever assessed the maturity of #cybersecurity implementation?

The #ZeroTrust #maturity model assessment by #Microsoft provides you with great insights, where to start or which part of your security needs improvement.

Easy to use, easy to understand, great results and great guidance.

You can find the assessment tool here:

https://www.microsoft.com/en-us/security/business/zero-trust/maturity-model-assessment-tool

And if you need more info, then bookmark this Zero Trust resources page: https://www.microsoft.com/security/blog/2021/05/24/resources-for-accelerating-your-zero-trust-journey

Note-to-self: logging policy considerations

Few days ago I got a question from a security officer for guidance on event and system logging.

What I can recommend: a good guideline and indication is this from OWASP.
You know OWASP is THE reference for software security …. with their OWASP top 10 etc.

Check this: https://owasp.org/www-project-cheat-sheets/cheatsheets/Logging_Cheat_Sheet

Another reference from NIST see below, very handy.

These are fairly complete in terms of guideline.

What you should pay special attention to from a policy point of view is

Special accounts

  •  Sensitive accounts
    • Highly priviliged accounts
    • Admin accounts
    • Service accounts
    • …
  • Sensitive systems
    • Domain controllers
    • Application servers
    • …
  • Sensitive data
    • HR data
    • Finance data
    • Legal data
    • …

Regarding the classification of accounts, check these:

For the users you also have to think carefully about events

  • Large volume of failed logons from sensitive users, may indicate
    • Attack
    • Denial of service
    • Hacking
  • Attack on the password database, large volumes of password change attempts …
    •  Smart password ‘testers’ will stay just below the blocking limit ..
  • Successful logons from special accounts at abnormal places or times
  • Changing the rights of sensitive accounts
    • Promotion of regular users to admins or other sensitive accounts in AD or central database

CLASSIFICATION

Make sure you have a data, user and system classification policy.
Define roles and / or categories.
Which objects are “not important”, “not sensitive”, sensitive, important, critical.
The protection must be tailored to the category type.

STORAGE

In addition, you should also write a policy on saving data.
This often poses a logistical problem with disk space.

If you know that sometimes attacks are only detected after 200-300 days, you should be able to do a forensic investigation in that period.
But that does not have to be on live data, if it is in backup, that is also good.

In terms of operational data you have to decide how much should be available immediately, for immediate consultation.
For example, that can be 1 month. (if the system can save so much)

BACKUP

Ensure that a backup can be guaranteed for a year (combination of full / differential and / or incremental backups or virtual snapshots …)
This is not a fixed period, but depending on risk management this may be more or less.

IMPORTANT: Time synchronization

Also make sure that you require NTP time synchronization, so that the clocks are exactly matched to each other on all systems.
Log analysis is impossible without correct timing.

SECURITY

Ensure that logs on source systems cannot be deleted by administrators.
Ensure that the logs following are shielded from system owners;
Ideally, you are obliged to store logs centrally (for example in a SIEM system).

Secure backups

Consider managed encryption of data and backups (not ransomware or malware).

Healthy logging and healthy backups

Make sure to test backups and restores!

Check the logs and backup for malware.

LOG CENTRALIZATION

Store logs centrally with sufficient storage capacity, security and backup.

LOG MANAGEMENT

A good management process and regular inspection must become mandatory.
Ensure monitoring for special events or special trends (sudden growth or sudden decrease or disappearance of logs)

Arrange forensic surveillance / detention if a burglary or data breach may need to be reported to the government / DPA / police.

The NIST documentation below provides useful hints and tips about the type of systems, routers, switches, firewalls, servers …

LEGISLATION

Take into account legislation such as GDPR or ePrivacy or others that impose your obligations (legal, judicial, international, fed gov, …)

EXPERIENCE

View and learn from past incidents and known use cases or accidents, which give a clear hint of what protect first.

PDCA – plan-do-check-act

Require a regular review of the policy and the rules, ensure that the guidelines are updated to the requirements and changing situations.

It is difficult if you find out after the facts that your log is not working properly.

Other references

And this is also a reference (NIST)

That alphabet of Security starts with I of “Identity”

It’s an understatement to say security is moving fast, it’s changing very rapidly and the pressure to keep up with it, increases too.

From various angles, people in IT (as in Information Technology), are under fire to keep the infrastructure secure. Cloud is getting mature, new features pop up every week.
It’s almost a contradiction, but also legislation is catching up to close the holes regarding the protection of people’s security and privacy.

In many cases, the first reaction of customers, management, ITPros, Developers, DevOps,… is to look for the ultimate and ideal tool that will help to plug the security hole.

But if you only focus on the tooling, you’ll discover rather sooner than later, it is not sufficient to get your security watertight.
One of the basic reasons is that tools can’t be implemented properly without involving people and processes. I don’t need to explain the PPT (people-proces-technology) or PPP (people-proces-products) triade, right?

Lots of security management approaches and certifications handle this triad (ISO27001, CISSP, … I’ll cover that another time.

(credits: smart picture of ITGovernance.co.uk)

Rather than diving into the search for a tool, you better take a step back and consider first.

What’s the primary function of security?
Protecting an item that you want to keep (safe), right?

[The reason (“why”) for keeping it safe = the CIA triad, Confidentiality, Integrity and Availability]

When you think about the processes (“how”) to secure  an asset (anything that is worth securing), there are 3 basics actions you need to define

  • authorization: what you can do with the asset (the CRUD stuff, create/read/update/delete)
  • identification: who needs the authorization?
  • authentication: the method to proof your identity (using passwords, passes, cards, 2FA, MFA, …)

This is essentially the foundation of my credo “no security without identity”

Just by interpreting the basic components of security, you directly hit the “PROCESS” part of the PPT triad.
Now, here’s were most technical people get into trouble… not knowing how to put this in practice.

But let me ask you a simple question: within the normal, usual businesses or companies, where does the identity process typically start?
Yes, correct, HR (Human Resources)

The second question: can you name at least 2 typical high-level HR processes (for people).
Answer: something like “hire” and “fire”, or synonyms like “onboarding/off-boarding”, “termination”, “end-of-life” (but that sounds pretty dramatic when talking about people…).

These 2 events announce the beginning and the end of a lifecycle, the identity lifecycle.
And to make it complete, you also need to define the life-in-between as people change over time.

BTW, just a small side step here: this does not apply to humans only, but any other asset in your environment has pretty much the same cycle and it does not matter if it’s considered “IT” or not… computer, certificates, smart cards, disks, tapes, … but also cars, documents, …

This idea to consider the lifecycle as universal, is a great approach to explain the “identity lifecycle” to non-techies that get involved in the identity lifecycle processes.

This is the common ground you can use to talk to HR people, business managers, Executive level, …

Now, if you look on the internet for pictures on identity lifecycle management, you’re smashed with a lot of complex schemas…

google_identitylifecycle

Many of results are variations of 3 essential processes

hire-change-fire1

Depending on your background you might name them differently, like:

1AA.png

For the sake of simplicity, when teaching IDM and security workshops I usually only keep the keywords “Hire”, “Change” and “Fire”.
Short and easy to remember for most people.

For your understanding, the circle approach  would assume you start over again after the “Fire” block, but that’s not always the case. The cycle might stop.
So, the approach below is easier to visualize for most people.

Clockwise:

  1. Starting the cycle at (1),
  2. updating the identity at (2),
  3. exiting the cycle at (3)

hire-change-fire2

As I mentioned, earlier, virtually any IT or asset related proces is basically working like this.

Now, let’s take it a step further… How does identity management control security?

A first thing to consider is the typical length of the hire-change-fire modules.

How many tasks/steps does it usually take to complete each of the 3 steps?
Keep the asset in mind and keep it simple…

Typical actions in a hire process:

  • signing contract
  • getting an network/AD account
  • getting an email address
  • getting building access
  • IT stuff (laptop, …)
  • …

Pretty straight forward…
How much time would it take, in simple cases to start working?  Hours if not days.

What about the change process? For example, you get promotion to team lead or head of department…

  • hand over your tasks to peers
  • get ramped up on new job
  • in some cases, there is segregation of duties, getting rid of existing rights permissions
  •  getting access to new environment
  • changing communications channels (notifications to stakeholders of change)
  • …

In reality, this usually takes a few weeks.

And what are the typical things your consider for the “fire” process?

  • informing stakeholders/customers
  • disabling the account
  • changing password
  • lock account
  • removing access
  • extracting documentation form personal storage
  • move documents to manager or team
  • handing over ownership
  • knowledge transfer
  • data backup/archiving
  • cleaning the mailbox
  • deleting the account (* not always allowed for various reasons)
  • sending legal / tax documents
  • and more…

As you can understand, this entire termination process might take months… In many situations the termination process must be executed in different steps, like:

  • Disabling the account till x+30 days (for example, revert in case the person gets a renewal)
  • Removing access on x+60 days
  • Kill mailbox on X+90
  • Remove the account on X+1y (or even: never)

In some cases accounts must be kept for legal reasons or tracking/cybersecurity reasons…

The further you go in the lifecycle, you need to combine more tasks, and tasks or decisions get more complex.

Overall you can distinguish 2 properties of these processes: duration and complexity. Both go up.

complexity

procesduration

Now, when considering security, why is this important?
Instead of discussing the impact of successful processes, it’s easier to find out what happens if it fails.

WHAT IF… (the process fails)??

Let’s run through the cycle again….

What if the “Hire” process fails?

  • you can’t access the building
  • you do not get an account
  • you can’t logon
  • you can’t access documents
  • …

Basically, on your first (few) day(s) you can’t work. Sorry!
But what’s the balance for security: just great, because the risk is nearly 0, except for a bad start and a bit of reputation damage..
At the end: you can’t do any harm, essentially.

In case of the “change” process, a larger part of the tasks and operations will impact the security posture.

When your “change” process fails,  for example

  • you can still access your old documents
  • you get more access (eg collecting access of your old and new role)
  • you start collection sensitive accesses over time
  • managers don’t know
  • user profiles get copied from existing colleagues in the same team (no ‘reset’ or the permissions before the new ones are assigned)
  • …

So for this second piece of the circle, the impact might be significant, over time.

But for the “end-of-life” the story is completely different, a failing “deprovisioning” scenario has major impact on the business and IT process

  • accounts stay active
  • accounts not being disabled
  • access not removed
  • active accounts not detected
  • account with highly privileged access still active
  • accounts being deleted too soon
  • unauthorized users that have access to critical resources
  • hackers go undetected for a long time, using sleeping accounts
  • hardware not returned,
  • data stolen,
  • over-use of budgets to software licenses that are not revoked
  • access badges allow unauthorized access to your building and environment
  • failure to ‘deprovision’ old hard disks properly expose your company data to interested (unauthorized) parties…
  • …,

It’s clear that a failing deprovisioning/end-of-life process has major impact on your enterprise security.

risk.png

And hackers or disgruntled employees like that.

Of course you can imagine the benefits of an efficient and effective end-of-life process. It’s the opposite.

Does that require you implement an automated identity management?
No.

That’s where ISO27001 and eg GDPR surprises a lot of people.

Once you’ve got the basic processes in place you can discuss tooling, not the other way around.

questforsecurity

You have
no security without managing your identity.

you want
no identity without security.

Did I mention  that I’ll be presenting more of this fun stuff on TechoRama 2017.
Check it out here: http://sched.co/9M94

I’m very proud to present a session on the ABC of identity: Maximizing security with 10 simple processes.

 

Note-to-self: DNS naming best practices for internal domains and networks

Just a few days ago, I’ve got a question from a customer regarding the DNS naming best practices for internal DNS and AD domains…

As it’s not a daily job to setup a new AD domain and internal DNS (from scratch…), so it might help to share the results of my investigation, that have lead to confirm my practical experiences.

Apparently it’s a pretty frequent topic on AD and network platforms. Plus there are some strict technical guidelines that apply here, even for internal DNS configurations…

The short answer, as best practice:

  • Microsoft strongly recommends to register a public domain and use subdomains for the internal DNS.
  • So, register a public DNS name , so you own it. Then create subdomains for internal use (like corp.pgeelen.be, dmz.pgeelen.be, extranet.pgeelen.be) and make sure you’ve got your DNS configuration setup correctly.

Below more detailed explanation. Luckily enough there is some nice reading material out there to prove the statement, so make sure you bookmark this page 😉

But first we need to clarify a few things…

AD Domain vs DNS name

The AD domain name is NOT the same as the DNS name, but they are linked.

AD Domain names are mainly used within AD operations, mostly LDAP queries for AD functionality, while DNS is rather a network level solution for name resolution on IP level (to solve the machines or application names to IP addresses).

Essentialy this difference allows you to use a ‘internal’, private AD domain name and use a public, registered DNS name.

When you look into discussions and documentation on this topic, you’ll also see that the AD domain short name is referred as NetBIOS Name (as in the AD logon name <DOMAIN>\<username>).

For example

  • AD Domain name: CORP
  • DNS name: corp.pgeelen.be

See here for more explanation: https://technet.microsoft.com/en-us/library/bb676377

You can also ‘unlink’ the AD domain name from the DNS name, then you get a disjoint namespace, as explained in previous link.

For Example

  • AD Domain naam : CORP
  • DNS naam: intranet.pgeelen.be

Check this forum discussion: https://social.technet.microsoft.com/Forums/windowsserver/en-US/f6ac34e8-4b35-4c3b-a60f-179f68d6eb24/ad-domain-name-vs-dns-domain-name?forum=winserverDS

And also: https://technet.microsoft.com/en-us/library/cc978018.aspx

Dummy DNS name vs official DNS name

In the past, lots of people chose to use a dummy, unofficial TLD (top-level-domain) for their internal network, likedomain.lan, domain.local of domain.internal (and also domain.internalhost)

But this can get you in serious trouble.

Because these names are not supported by internet standards, the most important RFC on this is: RFC 2606 (http://tools.ietf.org/html/rfc2606)

This RFC standard is very explicit on chosing domain names for voor private testing and documentation

  • .test
  • .example
  • .invalid
  • .localhost

But also for documentation some 2nd level domains are reserved

  • example.com
  • example.net
  • example.org

As you can see, these names are created for testing and not for production.

Plus, if the public naming standards change or additional names are released you might be using a name you don’t own and that can be routed to the internet, which conflicts with the initial use.

Therefore the technical conclusion is fairly straight forward: register a public DNS name and use it for your internal DNS resolution.

So the use of <yourinternaldomain>.be is technically correct but it doesn’t stop there.

There are some important consequences.

Allow me to take the discussion a step further.

You have to make a choice on the DNS zones:

  • using a single DNS zone
  • Using subdomains
  • using different DNS zones

 

Using a single namespace (for internal and external hosts)

Some customers use the same DNS zone for internal and external usage. But there are some important disadvantages:

  • mismatch between security zones (like intranet, extranet, dmz and) and DNS naming
  • when adding / merging domains the DNS is subject to redesign
  • less flexible, less automated DNS operations
  • conflict in authority with internal DNS and external DNS (managed by internet provider)

You might face some practical issues like:

  • conflicts in DNS,
  • instable operations and sub-optimal performance
  • network issues
  • complex configuration
  • less or no automated DNS operations, more manual operations
  • keeping DNS under control is less obvious

Plus, you’ll face some consequences regarding network security, by the lack of segregation of (DNS) duties.

So: Single DNS domain is absolutely not advised.

Using different DNS names and zones

It’s completely the opposite of the previous approach. From DNS level, this is fairly simple setup, but you need to duplicate or multiply DNS configurations. And from a user perspective it might be complex or confusing, or not transparent, and inconsistent

DNS sub-domains

This is a frequently used technique to use the same TLD (top level domain) and separate the zones by subdomain. Eg “intranet”, “extranet”, “DMZ” for ‘internal’ zones en just plain <domain>.<tld> for public DNS.

For example:

  • intranet.pgeelen.be or corp.pgeelen.be (if your AD is named ‘CORP’ )
  • extranet.pgeelen.be for applications or partner facing websites
  • DMZ.pgeelen.be for applications that need DMZ for data protection or publication,
  • and master suffix .pgeelen.be for public websites (managed by your Internet Provider)

The forum post I mentioned earlier discusses a technique called “DNS split brain”:

In fact you have one DNS name space, but with sub spaces per zone.

This is a bit more complicated setup as you need to make sure the DNS servers forward the requests to the applicable zones correctly.

And it does require some planning and cooperation with your internet provider.

Microsoft strongly suggests to work with subdomains, within a publicly registered TLD domain.

Check: Creating Internal and External Domains op https://technet.microsoft.com/en-us/library/cc755946(WS.10).aspx

Design Option Management Complexity Example
The internal domain is a subdomain of the external domain. Microsoft strongly recommends this option. For more information, see Using an Internal Subdomain. Easy to deploy and administer. An organization with an external namespace contoso.com uses the internal namespace corp.contoso.com.
The internal and external domain names are different from each other. For more information, see Using Different Internal and External Domain Names. More complicated than previous option. An organization uses contoso.com for its external namespace, and corp.internal for its internal namespace.

 

On top of that you need to be aware of a few rules regarding naming standards: https://support.microsoft.com/en-us/kb/909264

 

To conclude, please find some useful reference info in one spot below: