I don't think you need to be too concerned. There are many legitimate reasons to have the UDP processes you have identified.
As you have noted, lsof can be used to find out which program is associated with the socket. Note that you will need to use sudo to run the command if you want to see information for processes which are not owned by the current user.
The . is the interface and port. If the interface is *, it means that the socket is bound to or can bind to all interfaces i.e. 127.0.0.1/localhost the IP of your ethernet or wireless interface and possibly the 224/multicast interface.
If the port is listed as *, it normally means there is no active connection to the port and there is no defined or well known port used by that service or it is a service that allocates ports dynamically and there is no current connection. When there is a connection, there will also be something listed in the status column, such as LISTEN, ESTABLISHED etc.
UDP ports are broken up into 3 basic groups 0 - 1023 used for common, well known services. Ports 1024 - 49151 for IANA-registered port use and 49152 - 65535 which are available for use by services and can be assigned dynamically as needed (assuming nothing else is using the port of course).
With respect to general security, there are a few basic principals you should follow
Turn on the OSX firewall. This will limit what can connect and to what ports. In general, the standard config allows your services to connect to external addresses but only allows external address to connect to you for either ports you allow or when it is part of some already established session - for example, if you have initiated a service which as part of that service, the remote system needs to communicate back to you on a UDP port.
Disable any services you don't use. For example, if you don't use OSX data sharing services, turn them off. Likewise, if you are connected over a wired connection and don't need wireless, turn it off. If you don't use/need location services, turn them off etc.
Some services can be configured to only listen on specific interfaces or only allow connections from specific hosts. This is more common with TCP, but can be done with some UDP based services. However, you need to be careful as you can break or adversely impact on a service if you restrict it incorrectly.
The key point is that you don't rely just on a single layer of protection. You have multiple layers so that if one layer should fail (due to a bug, misconfiguration, zero-day vulnerability etc) other layers of protection may provide protection. For example, I have a firewall on my OSX system, a firewall on my router and various security settings on my internal networking switch.
One of the benefits of something like OSX over Linux (for example) is that it has pretty reasonable defaults. Provided you follow the advice/best practice recommended by Apple, your in a pretty good position. However, one of the disadvantages of this approach is that it is often much harder to tweak the configuration to meet your specific needs. With a Linux system, you have full control and can tweak it to be as locked down as you like. However, you also have the power to completely screw it up. With OSX, Apple has taken some of that power away or made it very difficult to get to, so you have less chances of screwing it up. However, when Apple screw it up, then everyone is at risk. The other problem is that because it is so standardised,it provides a bigger target. Linux, with less standardisation means that if someone wants to find an exploit, they also have to find a Linux box with just the right mixture of software and configuration in order to have assurance the exploit will work. This is why I use my Linux system for high risk situations/environments and my OSX system for low risk situations. I spend less time tweaking and configuring my OSX system and it is convenient. I spend more time with the Linux system and while it is less convenient, it is more secure.
It should be noted that as UDP is a connectionless protocol which does not have the 3-way handshake of TCP, the security threats are a bit different. UDP is sometimes referred to as an unreliable connection because it does not have all the checks and balances of TCP sockets. It is used where loss of datagrams or datagrams arriving out of sequence is not a problem. It therefore tends to be used when you want to send/receive simple and low importance data. It isn't suitable for bi-directional communication where the order of packets is important and there is likely to be a 'session' involving a bi-directional conversation/communication. This doesn't mean you can't do such things, but that it is typically harder and less reliable than a TCP connection.
One of the most common threats based around UDP is denial of service. Because there is no handshake in the protocol, it is very easy to spoof the originating source IP. Many of the reflection and amplification denial of service attacks use this technique. For example, I could use the NTP protocl config flaw which allow you to query an NTP server over UDP to request a list of all the servers which have used it to synchronise their time, but instead of having my IP address associated with the query, I spoof a victims address. The NTP server receives the request and sends the response back to the spoofed IP I used. This is the reflection part. As the response is much large (more bytes) than the request, the data returned is larger than the data sent - this is the amplification part. If I do this to a large number of NTP servers, suddenly my victim starts receiving all these UDP datagrams it did not request. You can't do this easily with TCP because when I spoof the address, the destination I send the data to immediately tries to do a handshake with the spoofed IP I used. The real host with that IP will receive this handshake attempt and essentially go "eh What?" and the handshake will fail because it did initiate and doesn't know anything about the connection.
