We have never transmitted, processed or stored credit card information in the past as we did everything via PayPal so we never needed to be PCI compliant.
However, we are launching a new online store and by having a seamless checkout where credit card information in processed without redirected to PayPal, we need PCI compliance now.
We are going to consult a Qualified Security Assessor Company to guide us through getting and maintaining PCI compliance. However, I wanted to get a decent idea of what i'm looking at before consulting them, before they try to sell you every service in the house that you may not need.
In terms of PCI compliance, I understand it needs to be done on the software and hardware level and meet the 12 points + required. We are going with Magento Professional as it has a PCI compliant payment system, and we are going with a PCI compliant web hosting company (dedicated server). But in terms of software, do you need PCI compliance on EVERYTHING? Or just the software that transmits, store and processes credit card information?
For example, according to Magento, the Payment Software is PCI compliant, while the Magento Platform is not. So this allows you to make changes, modifications and customisations to Magento without affecting the PCI compliance of the payment software.
In other words, i'm asking, do you only need PCI compliance on the source code/software that deals with transmitting, processing and storing credit card information? These 'Qualified Security Assessor Companies' give the impression that all source code needs to be checked for PCI compliance, which is impossible!
For example, in the case of Magento, can I make changes and modifications to it and still remain PCI compliant? So long as the payment module is untouched since it is PCI compliant and the web hosting, server and OS is PCI compliant?
I mean the php, javascript, mysql stuff that does not deal with credit cards don't need to be compliant do they? they will be on the same server of course.
The basic answer is that it depends. In general, only the source code that deals (or can deal) with the sensitive and protected data of PCI needs to be PCI compliant. However, this means that if other areas of your code have access into the secure areas, you need security there as well. If another area of your application were to be vulnerable to SQL injection, for instance, it might compromise your credit card systems. That is why some people will lean towards PCI compliance for all software. There has to be some assurance that a poorly-written piece of software can be exploited to compromise the safety of the data.
I say it depends because there is always some room for interpretation by those doing the inspection. However, the good news is that of all the standards, PCI seems to be the most direct and specific about what you need to do and what you cannot do. Here is more information about what PCI says directly:
https://www.pcisecuritystandards.org/documents/infosupp_6_6_applicationfirewalls_codereviews.pdf
The basic issue here is to be sure that the site cannot be exploited anywhere. If you develop sufficient "firewalls" between your application areas (credit card data versus normal website), it will go a long way towards showing that you only need to scan some code. Also, as the above document states, you don't have to do a source code review in order to be PCI compliant. However, your application needs to be extensively tested to be sure it is safe from typical vulnerabilities.
I can't speak to the legal details of PCI compliance, but if I were an auditor of your system I would squawk very loudly if any non-certified code runs as the same userid that runs the certified code.
I'd also look pretty closely at what setuid/setgid executables are on the system, what runs as root or with elevated capabilities(7) that could influence the PCI-compliant software, and I'd probably demand mandatory access control tools such as AppArmor, SElinux, TOMOYO, or SMACK, and an appropriate configuration that prevents tampering with the PCI-compliant portions of the server by untrusted execution domains.
Related
Can we use AWS Device Farm to test anti-virus application by installing real malware on rented devices?
AWS's AUP includes the following wording:
You may not use, or facilitate or allow others to use, the Services or the AWS Site: ... to violate the security, integrity, or availability of any user, network, computer or communications system, software application, or network or computing device;
So with regards to installing malware or exposing the devices to live virus or malware payload, the answer is an unequivocal no.
However, I would imagine that as with standard EICAR test strings, you could test file contents for various pattern matches and remain within the bounds of the AUP, ie by including a substring of a particular known malicious payload to test detection. The moment you allowed known malicious code to execute you would be in violation of the AUP, and depending on AWS's inbuilt scanning they may detect and block your access proactively regardless.
So to summarize, the answer is no, you'd need to build your own lab on your own equipment to do testing of this nature.
I'm thinking about creating EC2 instances that run industrial software. This EC2 instance should be able to receive data from Serial COM port. Is it possible to connect things like this, with eventually a serial tunneling or anything else ?
There are two parts to the answer to this question.
Yes, absolutely, this is possible in theory.
...but it might not be practical or possible for the specific purpose/application/device that you have in mind.
Terminal servers are a simple illustration of the principle. Note that in this sense, I'm not referring to a Windows Remote Desktop "terminal server," but to the generic device commonly called a terminal server which, in its simplest form, is a physical device that speaks a serial protocol such as RS-232 on one side, and TCP on the other side. RS-232 is the wire protocol of a PC "COM" port.
But a computer, configured with appropriate drivers, can have a "virtual" COM port that appears -- to software on the computer -- as an interface just like a physical COM port, but the driver for that COM port, instead of providing the software with access to literal hardware is in fact managing a TCP connection, tunneling the send and receive bits from the COM port back to the physical port on the terminal server.
The terminal server could be an actual, dedicated terminal server device, could be a full size PC, a microcontroller with network capability, a Raspberry Pi with a USB-to-Serial adapter... there are a lot of potential variations.
Problems to consider:
A lot of older industrial software seems very poorly written. This is my impression, anyway. The implementers, perhaps working at the edges of their expertise, having made certain design assumptions that work on physical COM ports but may not be compatible with such a deployment. This is less likely to be true if the systems are newer, and run on a modern OS, but back in the early days of Windows and before, this was a real mess.
License key dongles, if present, might rely on peculiarities of physical COM ports that are difficult or impossible to virtualize. The terms of the software license may constrain you from doing this.
Some equipment may be unnecessarily sensitive to the delay that is introduced by the distances involved. There are, for example, 22 ms of round-trip time in the Internet path between one of my facilities and the nearest AWS region. At 9600-8-N-1 that is the time to transmit ~23 bytes, and that's best case -- the virtualization layer and encryption will add more. The machine or the software may or may not be well-written enough to accept that kind of delay, which does not occur on a physical, local COM port.
If the machine is being controlled (not simply observed) then you need to absolutely ensure that you are not creating a safety hazard by separating the machine from its software through a virtualization layer.
"Sharing" control of a machine by software on multiple EC2 instances seems like it might be implied by your illustration, but this potentially adds an entirely different set of complexity.
In theory, yes, it's possible. I mean, even Windows remote desktop allows you to share a local COM port with the remote system, allowing remote software to access and control your local device.
In practice, this potentially requires a lot of attention to a large number of factors that vary by operating system as well as by the specific peculiarities of the devices and software in question.
EC2 connectivity is through the network interface, so I don't think a direct connection like the one you are asking is possible.
However, if you are talking about industrial devices supporting automation, chances are you can use MQTT or at least a MQTT bridge. If that's the case, you can take a look at AWS IOT Core
With AWS IOT Core you don't only get bidirectional connectivity between your devices and AWS, but also powerful analytics, device registry and management, and full integration with the AWS ecosystem.
We're trying to set up a Windows Continuous Integration server in the cloud that has software with a particularly difficult licensing scheme (a certain embedded software compiler). This compiler either lets the user run with a dongle, or node locks the software to run on a specific set of hardware. Seeing as how we can't exactly ship off a dongle to Amazon to plug in to our machine for us, we want to use the node locked licensing scheme with this software.
However, in order for this license to remain valid, my EC2 instance needs to have a set of "static" hardware IDs. We don't actually know which hardware IDs this software will look for (and they won't tell us), but I'd like to know which hardware IDs I should expect to change with instance restarts, and which hardware IDs, if any, I can lock down through proper configuration of my EC2 instance.
For example, I already know that I can lock down the MAC address of the Network Interface using Amazon's Elastic Network Interface (ENI). Is there any other configuration I can do, or need to do, in order to get a set of static hardware IDs?
I know that there are nice UPnP stacks like "Developer Tools for UPnP Technologies" (http://opentools.homeip.net/dev-tools-for-upnp). This would work but I do not need all this functionality.
All I need is that I can see my device (in e.g. the Windows Explorer - Network tree) with a property page which publishes the device IP.
Is there a library that only announces the device?
GSSDP (libgssdp in most linux distros) is a small, reliable and well tested library that handles the announcement and discovery part of UPnP: it's trivial to write a small program that advertizes the device uri with GSSDP (see example).
However, nothing guarantees that your Windows Explorer shows all SSDP announced devices. Maybe you do know what it does but I thought I should mention it might show only devices that look like UPnP devices, or it might show only devices that look like UPnP AV devices, or might even only show devices that look like DLNA supporting UPnP AV devices...
How are Massively Multiplayer Online RPG games built?
What server infrastructure are they built on? especially with so many clients connected and communicating in real time.
Do they manage with scripts that execute on page requests? or installed services that run in the background and manage communication with connected clients?
Do they use other protocols? because HTTP does not allow servers to push data to clients.
How do the "engines" work, to centrally process hundreds of conflicting gameplay events?
Thanks for your time.
Many roads lead to Rome, and many architectures lead to MMORPG's.
Here are some general thoughts to your bullet points:
The server infrastructure needs to support the ability to scale out... add additional servers as load increases. This is well-suited to Cloud Computing by the way. I'm currently running a large financial services app that needs to scale up and down depending on time of day and time of year. We use Amazon AWS to almost instantly add and remove virtual servers.
MMORPG's that I'm familiar with probably don't use web services for communication (since they are stateless) but rather a custom server-side program (e.g. a service that listens for TCP and/or UDP messages).
They probably use a custom TCP and/or UDP based protocol (look into socket communication)
Most games are segmented into "worlds", limiting the number of players that are in the same virtual universe to the number of game events that one server (probably with lots of CPU's and lots of memory) can reasonably process. The exact event processing mechanism depends on the requirements of the game designer, but generally I expect that incoming events go into a priority queue (prioritized by time received and/or time sent and probably other criteria along the lines of "how bad is it if we ignore this event?").
This is a very large subject overall. I would suggest you check over on Amazon.com for books covering this topic.
What server infrastructure are they built on? especially with so many clients connected and communicating in real time.
I'd guess the servers will be running on Linux, BSD or Solaris almost 99% of the time.
Do they manage with scripts that execute on page requests? or installed services that run in the background and manage communication with connected clients?
The server your client talks to will be a server running a daemons or service that sits idle listening for connections. For instances (dungeons), usually a new process is launched for each group, which would mean there is a dispatcher service somewhere mananging this (analogous to a threadpool)
Do they use other protocols? because HTTP does not allow servers to push data to clients.
UDP is the protocol used. It's fast as it makes no guarantees the packet will be received. You don't care if a bit of latency causes the client to lose their world position.
How do the "engines" work, to centrally process hundreds of conflicting gameplay events?
Most MMOs have zones which limit this to a certain amount of people. For those that do have 100s of people in one area, there is usually high latency. The server is having to deal with 100s of spells being sent its way, which it must calculate damage amounts for each one. For the big five MMOs I imagine there are teams of 10-20 very intelligent, mathematically gifted developers working on this daily and there isn't a MMO out there that has got it right yet, most break after 100 players.
--
Have a look for Wowemu (there's no official site and I don't want to link to a dodgy site). This is based on ApireCore which is an MMO simulator, or basically a reverse engineer of the WoW protocol. This is what the private WoW servers run off. From what I recall Wowemu is
mySQL
Python
However ApireCore is C++.
The backend for Wowemu is amazingly simple (I tried it in 2005 however) and probably a complete over simplification of the database schema. It does gives you a good idea of what's involved.
Because MMOs by and large require the resources of a business to develop and deploy, at which point they are valuable company IP, there isn't a ton of publicly available information about implementations.
One thing that is fairly certain is that since MMOs by and large use a custom client and 3D renderer they don't use HTTP because they aren't web browsers. Online games are going to have their own protocols built on top of TCP/IP or UDP.
The game simulations themselves will be built using the same techniques as any networked 3D game, so you can look towards resources for that problem domain to learn more.
For the big daddy, World of Warcraft, we can guess that their database is Oracle because Blizzard's job listings frequently cite Oracle experience as a requirement/plus. They use Lua for user interface scripting. C++ and OpenGL (for Mac) and Direct3D (for PC) can be assumed as the implementation languages for the game clients because that's what games are made with.
One company that is cool about discussing their implementation is CCP, creators of Eve online. They have published a number of presentations and articles about Eve's infrastructure, and it is a particularly interesting case because they use Stackless Python for a lot of Eve's implementation.
http://www.disinterest.org/resource/PyCon2006-StacklessInEve.wmv
http://us.pycon.org/2009/conference/schedule/event/91/
There was also a recent Game Developer Magazine article on Eve's architecture:
https://store.cmpgame.com/product/3359/Game-Developer-June%7B47%7DJuly-2009-Issue---Digital-Edition
The Software Engineering radio podcast had an episode with Jim Purbrick about Second Life which discusses servers, worlds, scaling and other MMORPG internals.
Traditionally MMOs have been based on C++ server applications running on Linux communicating with a database for back end storage and fat client applications using OpenGL or DirectX.
In many cases the client and server embed a scripting engine which allows behaviours to be defined in a higher level language. EVE is notable in that it is mostly implemented in Python and runs on top of Stackless rather than being mostly C++ with some high level scripts.
Generally the server sits in a loop reading requests from connected clients, processing them to enforce game mechanics and then sending out updates to the clients. UDP can be used to minimize latency and the retransmission of stale data, but as RPGs generally don't employ twitch gameplay TCP/IP is normally a better choice. Comet or BOSH can be used to allow bi-directional communications over HTTP for web based MMOs and web sockets will soon be a good option there.
If I were building a new MMO today I'd probably use XMPP, BOSH and build the client in JavaScript as that would allow it to work without a fat client download and interoperate with XMPP based IM and voice systems (like gchat). Once WebGL is widely supported this would even allow browser based 3D virtual worlds.
Because the environments are too large to simulate in a single process, they are normally split up geographically between processes each of which simulates a small area of the world. Often there is an optimal population for a world, so multiple copies (shards) are run which different sets of people use.
There's a good presentation about the Second Life architecture by Ian Wilkes who was the Director of Operations here: http://www.infoq.com/presentations/Second-Life-Ian-Wilkes
Most of my talks on Second Life technology are linked to from my blog at: http://jimpurbrick.com
Take a look at Erlang. It's a concurrent programming language and runtime system, and was designed to support distributed, fault-tolerant, soft-real-time, non-stop applications.