One Company. One Vision. 1 Source.

Today you will notice a new look and a new name on our website. Here’s a quick explanation of what the changes are all about.

1 Source Inc. today announced the acquisition of our joint venture partner Energy Enterprise Solutions, LLC, creating one company with one vision. Today, we are a Veteran-owned, minority-owned, award-winning small business, leveraging both companies’ leadership and legacies to continue to provide unsurpassed services to our IT and business strategy clients.

We have successfully novated all of our government contracts, and we are excited about our future. Our valued clients will receive the profound experience, knowledge and track record of an experienced IT and business strategy services company from a Veteran-owned, minority-owned, award-winning small business.

With nearly two decades of experience delivering quality IT services and business strategy to our clients, we have the expertise to get our clients’ initiatives successfully completed on time and within budget. Our enduring history of delivering customer success stories is built on one solid foundation: an unwavering commitment to delivering the highest performance quality combined with exceptional service.

We are exceedingly grateful to all our clients and colleagues for our many years of growth and success. Thank you for being part of our journey. We look forward to continuing to serve our clients, our colleagues, our community, and ultimately our country, in the years to come.

William Teel and Matt Collins

Additional Posts


Cyber Security: DNS Best Practices for Government Agencies

Getting Ready for BYOD.gov: Best Practices in BYOD for Government Agencies

 

Cyber Security: DNS Best Practices for Government Agencies (Part ll)

Part ll

If you haven’t already, please visit Part I of this multipart series on DNS Security. For those who are already managing an inventory list of your DNS servers, while blocking port 53 for everything else, then you are ready to start doing DNS Response Policy Zones (RPZ) to block malicious domains. In fact we don’t want to just block the events, but log them for analysis (we will get to that later).

Many federal organizations are already utilizing a managed service provider to provide DNS/DHCP/IPAM (DDI) for them. Please contact them for more information on subscribing to RPZs, performing black-holing and walled-gardens for DNS. They may already have the infrastructure available in cloud format to block, log and analyze those bad DNS queries for you at the flip of a switch.

But to simplify things, RPZ is basically a flat text file that can define the resolution of names to addresses. See below:

Now the interesting thing about how this zone file works is, that if a user to were to attempt to visit http://goggle.com instead of http://google.com by mistake. When their computer makes a query to your DNS server, it will respond by saying goggle.com is located at www.google.com, since www.google.com is still not an IP addresses, it will then perform a second DNS query for www.google.com, in which case your DNS should return the IP address of www.google.com.

Goggle.com is an example of a cyber-typo-squat, which occurs more frequently that one might suspect in an organization of thousands of employees conducting hundreds of such entries a day. Goggle.com is considered an infected web resource by many security devices, but should not cause harm to your computer if you were to test your DNS by performing an nslookup on it in your CMD prompt.

“nslookup goggle.com”

If you successfully received an IP addressing looking like: 104.156.226.89

Then your DNS did not protect you and you would be left relying on the security of your proxy and Anti-Virus to protect you against goggle.com.

In the other example, if a user to attempt to visit the malicious domain “evil.bad”, the DNS server would respond with the IP address 127.0.0.1, which is the local-loopback, preventing any communication with the evil.bad domain. We can later replace that 127.0.0.1 address with the address of a walled-garden server, which would intercept the request, logging and then alerting on any malicious traffic.

Creating and managing a Policy Zone can obviously be very demanding, but luckily there are multiple free resources and zones out there that you can set to automatically subscribe to, or manually feed into your own zone files which can be as easy as setting this configuration ( with rpz.provider.com being replaced by the actual server):

Despite the efforts of dedicated security professionals who specialize only in domain black-listing, there have been rapid increases in the amount, scale, and innovation by adversaries to operate from domains that escape the RPZ blacklists on a daily basis. One unique option that is not currently offered as a service from other providers is a Top Level Domain Blacklist (TLD). TLD are the ends of domains, such as .biz, .me, .info. It can obviously be very risky blocking the entire TLD, as many legitimate websites will be blocked along with it. Despite this, we have observed great success with Federal organizations who tailor their own custom RPZ lists for TLD that fill the gaps that other RPZ lists or Proxy URL categories miss. 

Such as inappropriate sites:

.ADULT

.PORN

.SEX

.SEXY

.XXX

 

Or hidden domains associated with crime, hacking and viruses:

.BITNET

.CSNET

.UUCP

.OZ

.SWIFT

.HIDDEN

.ONION

.HOME

.I2P

.BIT

.TOR2WEB

.EXIT

.DYN

.GLUE

.GNU

.ZKEY

.EMC

.COIN

For the full .TLD RPZ blocklist, please contact 1-Source to get a free copy.

Establishing and then integrating these multilayered DNS security services can be difficult, so we encourage readers to reach out to 1-Source for more information and consultation regarding implementing cyber security in their organization.

Cyber Security: DNS Best Practices for Government Agencies

Part I 

When assessing cyber security, one of the key technologies that many security professionals may overlook is DNS. The Domain Name System resolves names to addresses (e.g., google.com = 216.58.217.142), which provides much of the functionality required for typical internet usage. Without relying on any pen-testers, FISMA auditors, tools or scripts, we will easily explore the current state of your DNS and hopefully provide security insights.

Let’s go ahead and test the importance of DNS by purposely breaking your own DNS with these commands (be sure to type:  ipconfig /all | findstr DNS to save your settings before breaking it, ALSO another way to reverse this is to set it to DHCP netsh interface ip set dns "Local Area Connection;" dhcp) . Try the following commands (be sure to replace your Interface name with the appropriate one): 

Now attempt to go to http://google.com in a new tab or do any of your normal internet based activities (you may need to do ipconfig /flushdns to clear any caching). Most likely you will find its not functioning properly, but before fixing it, let’s explore some of the bypasses that insider threats or adversaries may perform to bypass a secured/hardened DNS to see if your network will prevent it.

One can bypass the need for DNS by knowing the IP address of the destination, for example we can still go to Google by visiting http://216.58.217.142 or even more deceptively by visiting http://3627735438/ or http://0330.0072.0331.0216 or http://0xD83AD98E and http://[2607:f8b0:4006:80a::1008]/ (if this IPv6 link worked, you will want to investigate your Proxy settings to see if there is a reason it is working and if IPv6 is secured, as you could have just found a security flaw).

Another way of bypassing DNS, especially if that DNS is black-holing, or not resolving the IP addresses of malicious domains or policy violation is that the adversary can temporarily switch to a new DNS to manually look it up. The following command, Name Server lookup is modified to explicitly use the DNS server 8.8.8.8 (which is Google’s public DNS) to find the IP address of google.com. Once this IP address is obtained, it can be visited by pasting it in the URL bar of the browser. 

IF this command worked, then already you have found a major security flaw in your network’s DNS architecture. By allowing external DNS queries, it allows insider threats; adversaries and malware to bypass any Domain Black-hole lists and DNS query logging. To put this in context, when thinking of the Cyber-Kill-Chain for example, Ransomware (malware that encrypts your data, holding it hostage for money) will often use DNS to query its Command & Control server (C2) to generate the encryption key. If your DNS security can prevent a successful DNS resolution, then it can’t contact the C2 server for the key, and then your data is never encrypted.

Before going deeper into the security of DNS, it is advisable to fix this problem by tightening down DNS queries to local resolvers only. This requires the following steps:

1. An inventory list of all your organizations DNS servers

2. Logs of all DNS traffic (port 53) sorted by IP

3. A sanity check against the inventory list versus the devices performing DNS queries

4. Applying a perimeter Firewall DNS whitelist rule (deny everything else)

 

An initial step to solve this is to implement this rule in your IDS devices, which will generate a list of IP addresses conducting DNS: 

alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"ONE DNS SOURCE Traffic Alert"; content:"|01|"; offset:2; depth:1; threshold:type limit,track by_src,count 1, seconds 60; classtype:misc-activity; sid:100000x; rev:1;)

Another option is to query the EINSTEIN-1 appliance monitoring your network for all port 53 traffic (for a full year if possible).

In addition, another quick way to discover internal DNS servers is to use this command, which will offer a verbose debugged trace of your DNS query path (it may require requesting a domain that would not be cached on your enterprise resolver): 

nslookup -d -d2 google.com

Querying your own name servers to find other name servers will assist, for example, in finding some Google DNS servers its possible by setting the type record to NS 

For many organizations these four steps are easier said than done, so we encourage readers to reach out to 1-Source for more information and consultation regarding implementing cyber security in their organization. 

Getting Ready for BYOD.gov: Best Practices in BYOD for Government Agencies

The BYOD (bring your own device) tsunami has already overtaken much of the private sector and for good reason: done right, BYOD can reduce costs, increase program productivity and effectiveness, help adaption to a changing workforce, and improve user experience. With so many potential benefits, it’s well worth considering how BYOD can be successfully implemented in a government context.

In this post (the first in a series of several to come) we will share some of our key findings about making BYOD work in a public agency context based on our own experiences with BYOD implementations for government clients.

Here’s what we have uncovered so far:

 

1. We are all learning as we go

Any project done today should be considered a starting point not a finishing one, because BYOD best practices will continue to evolve over time. Many unsolved issues remain, at least partly because the Federal government is still figuring out how to handle them. This includes basic logistical issues such as how to handle data-plan reimbursement, as well as more complex issues around additional security, privacy, and legal considerations. Until Federal guidelines are established, these issues will remain to be solved on a case-by-case basis.

 

2. Take it one step at a time

BYOD implementation works best as an iterative process. A good way to start is with supporting BYOD for commodity enterprise technologies like email and collaboration systems. You can then use that work to lay the foundation for expanding to more diverse, mission-specific applications and a broader scope of enterprise offerings.

In addition, consider the wide variety of potential applications. Depending on the context, BYOD can be facilitated through applications native to the device, downloaded or installable applications, or even a web browser.

 

3. The payoff is happier, more productive users

The private and public sector entities who have adopted BYOD solutions report that allowing employees to use their personal mobile devices to access company resources often results in increased employee productivity and job satisfaction.

This is not surprising, but it’s good to be reminded that the result of the work is not only better efficiency, but also all the tangible and intangible benefits of happy employees.

 

4. One size does not fit all

Some agencies will be a better fit for BYOD than others, because security needs will vary widely. From the Federal information security perspective, devices must be configured and managed with information assurance controls commensurate with the sensitivity of the underlying data as part of an overall risk management framework.

(Note: In a future post in this series, we will dive into a checklist you can use for evaluating whether BYOD makes sense for your agency.)

 

5. Cost-benefit analysis is essential

BYOD can and should be cost-effective, so a cost-benefit analysis is essential as the policy is deployed. It should take into account both potential increases in employee productivity and potential cost shifts.

For example, providing employees access to government services on their personal devices should help reduce the number of government devices that are provided to staff, as well as the life-cycle asset management costs associated with these devices. BYOD programs may, however, necessitate government reimbursement for voice/data costs incurred when employees use their personal mobile devices instead of government-issued mobile devices and additional enterprise infrastructure costs in handling the support of BYOD users. Additionally, overall costs may significantly increase for personnel who frequently communicate outside of the coverage area of their primary service provider and incur roaming charges.

The only way to be sure of where the cost changes will land is to do the math.

 

6. Security issues are an ongoing challenge

Implementation of a BYOD program presents agencies with a myriad of security, policy, technical, and legal challenges. These challenges are not only to internal communications, but also to relationships and trust with business and government partners. The magnitude of the issues is a function of both the sensitivity of the underlying data and the amount of processing and data storage allowed on the personal device based on the technical approach adopted.

 

Conclusion

Despite these challenges and obstacles, it’s worth emphasizing that at the end of the day BYOD is about offering choice. By embracing the consumerization of Information Technology (IT), the government can address the personal preferences of its employees, offering them increased mobility and better integration of their personal and work lives. It enables employees the flexibility to work in a way that optimizes their productivity, which in the end, is good for all of us. After all the government works for us, so anything we can do to help it work better helps us all.